金九银十这个词在程序员校招圈里喊了得有七八年但真到了每年九、十月份你才会发现它一点没夸张。牛客网上刷屏的笔试求助帖、脉脉上“有没有人收到面试通知”的追问、宿舍楼道里抱着电脑做在线测评的室友这些都是秋招季的标配画面。2023年58集团秋招后端移动端岗笔试是我当年印象很深的一场。先说结论这个岗位的笔试不走寻常路它既不像纯后端岗那样把算法题堆到让人头皮发麻也不像纯客户端岗那样疯狂追问Android源码细节而是把后端主力考点和移动端核心素养揉在一起考察你是否具备从服务端到客户端整条链路的全局视野。58同城的业务特点是信息分发招聘、房产、二手车这些典型的分类信息场景后端要扛住高并发检索和海量数据写入移动端要承接复杂列表、图片加载和IM消息推送所以笔试出题非常看重“业务落地能力”。这篇文章我会把这场笔试涉及的题型分布、核心考点、答题思路和实战技巧完整拆一遍所有内容结合我当时在牛客网看过的真题回忆、同行交流以及同类岗位的通用考法整理。无论你是准备投递后端岗还是移动端岗这套复盘逻辑都能直接用。1. 笔试全貌一场“后端为主、移动端为辅”的复合能力测验1.1 岗位定位与笔试风格分析后端移动端岗这个组合在后端和客户端岗位序列里都算一个比较特殊的存在。很多没接触过的同学会疑惑这到底是偏后端还是偏客户端我笔试前专门查过58同城的岗位描述它其实是想找一类“全链路工程师”——既能写服务端接口也能理解移动端如何消费这些接口在前后端联调、接口设计、性能优化这些环节能自己闭环。这就决定了笔试的命题风格不会只考某一端而是把两端串起来考。比如给你一个接口场景让你分析服务端该怎么设计然后又会追问移动端拿到数据后如何渲染、如何做缓存、弱网下怎么处理。这种“一条链路考到底”的方式在58的笔试里体现得特别明显。1.2 题型分布与分值结构根据2023年秋招实际笔试情况来看58的后端移动端岗笔试用的是牛客网在线评测系统整体时长100分钟题量和分值大致如下题型题量分值占比特点单项选择题20题30%计算机基础为主覆盖面广多项选择题5题15%易错点集中多选少选均不得分简答题3题20%偏场景设计考工程落地思维编程题2题35%算法为主难度LeetCode中等偏下这个分值分布很有讲究。算法题只占35%意味着它不想用算法题卡死所有人而是想借选择题和简答题筛出真正有工程经验积累的人。所以如果你算法能力一般但项目经验和基础功扎实这场笔试是很有机会突围的。牛客网的笔试系统支持本地IDE调试编程题只需要把最终代码粘贴到网页里提交所以平时习惯用IDEA写代码的同学不需要担心在线编辑器难用。1.3 高频考点地图把2023年这场笔试和同批次其他公司比如美团、京东、拼多多的考题放在一起对比你会发现58的出题重点有明显的业务导向。我当时整理了一张考点分布表覆盖了大概90%的考题方向现在翻出来看依然很有参考价值考察方向具体知识点出现频率计算机网络TCP/IP、HTTP状态码、缓存机制极高Java基础集合框架、并发编程、JVM内存模型极高数据库SQL编写、索引优化、事务隔离级别高Spring生态IOC、AOP、Spring Boot自动配置中高前后端交互RESTful接口、JSON、跨域、鉴权中高移动端基础列表优化、图片加载、网络请求中等算法与数据结构二叉树、字符串、动态规划、堆栈高这张表其实是很多互联网公司后端岗位笔试的“最大公约数”但58的特色在于移动端知识占比明显比纯后端岗高而且问法很落地。比如它不会直接问你“Android的RecyclerView原理是什么”而是给一个具体场景——“信息流滑动卡顿请分析可能原因并给出优化方案”。这种问法更考验候选人在真实业务里解决问题的能力光背八股文是答不好的。提示58集团后端移动端岗的笔试真正的难点不是题目本身有多深而是知识面跨度大。你需要在有限时间内从前端跨域调到后端接口设计再跳到移动端渲染优化脑回路切换跟不上就会慌。建议备考时把“前后端分离架构下的完整请求链路”作为主线去复习。2. 核心知识点逐项拆解计算机基础与Java后端必备2.1 计算机网络从TCP握手到HTTP缓存机制网络这块在58笔试里的考法偏应用型很少直接让你默写“三次握手的过程”而是喜欢换个场景问你“为什么连接建立需要三次握手断开却需要四次”。我当时遇到的一道选择题就是这个思路四个选项里有两个看着都对但只有一个是把“防止历史连接请求到达服务端造成资源浪费”这个核心原因讲清楚的。TCP三次握手可以类比成两个人打电话确认双方都能听能说A先问B“你能听到吗”B收到后回复“我能听到你能听到我吗”A再回一句“我能听到”这样双方才确认通信链路可用。之所以要三次而不是两次核心是为了防止客户端发出的失效连接请求突然到达服务端导致服务端白白建立一条没有意义的连接。如果只有两次握手服务端无法确认客户端的接收能力是否正常。HTTP相关考点同样是重头戏。状态码这块我建议重点区分301永久重定向和302临时重定向、304协商缓存命中、401未认证和403无权限这三组几乎每年必考。缓存机制也是高频题强缓存的Expires和Cache-Control优先级怎么判断协商缓存的ETag和Last-Modified存在什么区别如果要求“刷新页面时不走缓存”应该怎么做——这些细节在58这类信息流业务里非常实用因为移动端App大量依赖缓存来提升加载速度。2.2 Java基础集合、并发与JVM的经典考点Java在58后端技术栈里占主导地位笔试选择题里Java基础的分量很重。HashMap是万年不变的考点但我那次遇到的不是“HashMap底层数据结构”这种入门题而是问“JDK 1.8中HashMap在什么条件下会从链表转为红黑树”以及“为什么阈值是8”。这两个问题就需要你真正读过源码才能答得准——链表转红黑树的触发条件是链表长度超过8且数组长度大于等于64设计成8的原因是根据泊松分布在负载因子0.75的情况下链表长度达到8的概率极低属于一种概率上的安全阈值。并发编程也是高频区块。synchronized和ReentrantLock的区别、volatile的可见性和有序性原理、ConcurrentHashMap在JDK 1.8为什么放弃分段锁改成CAS加synchronized锁头节点——这些是出现频率最高的三个问题。我当时在简答题里遇到一个场景“多个线程同时对一个计数器进行自增操作如何保证线程安全且性能最优”这其实就是在考察AtomicLong和LongAdder的取舍。在低并发场景下AtomicLong的CAS自旋足够但在高并发下LongAdder采用分段累加再汇总的方式性能优势非常明显——这和ConcurrentHashMap放弃分段锁的思路殊途同归。JVM内存模型和垃圾回收主要出现在选择题。需要重点关注的是堆内存中年轻代和老年代的比例默认是1比2、对象什么时候从年轻代晋升到老年代年龄达到15或大对象直接进入老年代、Minor GC和Full GC的触发条件。58的笔试很少考JVM调参这种偏运维的题更多是考察你对内存区域划分的理解是否清晰。2.3 数据库与索引SQL题和慢查询优化的答题思路数据库这块58笔试的SQL题通常比较贴近业务会给你一张类似“用户职位收藏表”的表结构让你统计数据。常见考法包括分组聚合GROUP BY HAVING、多表关联JOIN、子查询去重、日期函数处理。编程题里如果有SQL的话一般占一道简答或选择不会单独出大分值的题但SQL写不写得对直接影响面试官对你的印象分。索引优化是选择题和简答题的共同热点。我印象很深的一道题是“有一个订单表查询条件为status和create_time如何建立索引最高效”标准答案是建立组合索引status, create_time把等值查询的字段放前面范围查询的字段放后面。这背后的原理是B树索引的匹配规则——最左前缀原则。如果反过来建立create_time, status的索引那么在查询status为某个值时create_time的等值条件就无法充分利用索引的有序性。慢查询优化是58这类信息分发业务非常关心的问题。简答题如果涉及数据库很大概率会问“一条SQL执行很慢你如何排查”。答题思路建议从外到内先用EXPLAIN看执行计划确认是否走了索引再看是否因为深分页LIMIT offset大偏移量导致扫描大量无用数据然后考虑是否需要对高频查询字段增加索引或冗余字段最后才是考虑缓存Redis挡流量。笔试时把这条链路写清楚比背几个索引口诀有用得多因为面试官能看出你真的处理过线上慢查询问题。3. 前后端链路与Spring生态把“分离”这件事讲透3.1 Spring Boot核心原理与IOC/AOP答题框架Spring Boot在58后端笔试里的地位相当于是“默认你会”。它不会直接问你“Spring Boot是什么”而是通过让你分析某个配置或组件的工作原理来间接检验你是否真的用过。IOC控制反转和AOP面向切面编程是绕不开的两个核心概念。我后来复盘时总结了一个比较清楚的答题框架IOC就是把对象的创建和依赖关系的维护从“自己new”交给“Spring容器管理”。你可以类比成吃饭——不用自己种菜、洗菜、炒菜而是去餐厅点菜厨师容器把做好的菜端给你。这么做最大的好处是解耦代码里不出现new关键字替换实现类时不需要改动调用方代码。AOP则是在不修改原有代码的情况下给方法统一添加日志、事务、权限校验等逻辑——就像商场里的自动感应门你不需要改造墙体结构只需要在门上装一个感应器进出时自动开门。Spring Boot自动配置也是高频考点。它本质上依赖EnableAutoConfiguration注解和spring.factories/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件启动时通过ConditionalOnClass、ConditionalOnMissingBean等条件注解按需装配bean。笔试里最常见的问法是“如何覆盖Spring Boot的默认配置”答案是在配置文件中显式声明bean或者使用Primary注解这比知道自动配置的源码更实用。3.2 前后端分离架构下的接口设计与数据格式约定58的笔试非常喜欢出“接口设计”类题目这大概是后端移动端岗的特色之一。我遇到的一道简答题是“设计一个App资讯信息流的列表接口需要支持分页加载和下拉刷新请写出请求参数、响应结构和异常处理方案。”这道题看着简单想拿高分并不容易。响应结构我建议直接套用统一返回体设计这是前后端分离项目里最约定俗成的做法。类似这样{ code: 0, message: success, data: { list: [ { id: 1024, title: 标题, coverUrl: https://example.com/cover.png, publishTime: 1695000000000 } ], hasMore: true, nextCursor: 1695000000000_1024 } }code为0表示成功非0表示业务异常data里不直接返回total而是返回hasMore和nextCursor这样能支撑移动端的“上拉加载更多”和“判断是否还有下一页”。分页方式建议用游标分页而不是传统的page/size。原因是信息流场景下用户会持续下拉翻页如果用limit offset做深分页页数越深MySQL扫描的数据越多性能急剧下降游标分页以最后一条记录的排序字段作为下次查询的起点理论上可以一直翻下去而不变慢。接口设计这里还有一个小细节很考验工程经验必须约定好时间格式。推荐用毫秒级时间戳long类型而不是字符串因为字符串在跨时区、跨语言序列化时容易出现格式不一致的问题。我在笔试中把这一点也写了进去后来面试时面试官特意提了一句说这个细节很加分。3.3 跨域问题的本质与四种解法跨域问题是前后端分离项目里绕不开的坎也是我当年笔试选择题和简答题都碰到过的考点。它的本质是浏览器的同源策略——协议、域名、端口三者只要有一个不一致浏览器就会拦截跨域请求的响应。这里注意请求通常是发出去了服务端也正常处理了只是响应被浏览器拦下来了。笔试能拿分的解法有四种第一JSONP利用script标签不受同源策略限制的特性只支持GET请求现在用得越来越少第二CORS后端在响应头加Access-Control-Allow-Origin等字段这是最标准的解决方案第三反向代理在Nginx或开发服务器里配置proxy_pass让前端请求同源的代理地址由代理转发到真实后端服务这是前后端分离项目开发环境里最常用的方案第四服务端渲染或网关层处理。我当时在Vue项目中配置过Vite或webpack的proxy代理原理就是第三种方案。平时debug时可以打开浏览器DevTools的Network面板如果看到“Access-Control-Allow-Origin”相关的报错先别急着怀疑后端检查一下代理配置是否正确——这是前后端联调踩坑率最高的一个环节。注意很多应届生在笔试里写跨域问题时只知道一个CORS如果你的答案里能把代理方式也讲清楚并且说明“CORS适合生产环境、代理适合开发环境”面试官会明显感觉你有真实联调经验。3.4 前后端分离项目实战经验如何转化为笔试答案58的笔试虽然没有直接让你写项目但简答和选择题里很多答案其实都来自你在实际项目中的积累。我备考的时候发现一个规律凡是在简历上写了“前后端分离项目”的同学笔试里关于接口联调、鉴权、部署的题目正确率普遍更高。前后端分离的核心流程是这样的后端写好接口文档Swagger/YApi前端根据文档进行页面开发联调阶段通过Mock数据模拟接口返回后端接口就绪后切换成真实地址开发完成后把前端构建产物dist目录部署到Nginx后端服务部署到服务器由Nginx统一处理静态资源请求并反向代理API请求。这一套流程在笔试中至少能用来回答三类问题跨域怎么解决Nginx反向代理、部署架构是什么样Nginx Spring Boot Jar包、为什么前端页面能访问后端数据同源策略下的代理转发。我在笔试简答题里就是按照“后端如何组织代码、前端如何调用、nginx如何分发”这个思路去答的虽然没有一个标准的“正确答案”但阅卷人一看就知道你确实独立做过完整项目。所以如果你现在还有时间准备强烈建议手写一个最简单的Spring Boot Vue前后端分离项目不需要复杂业务逻辑能把用户登录和列表展示贯通即可含金量远超刷十套题。4. 移动端方向考点性能优化与调试实操4.1 移动端列表渲染与图片加载优化58集团的App业务中有大量feed流场景列表性能直接决定用户体验。笔试中移动端方向的题目几乎都围绕性能优化展开最常见的是“RecyclerViewAndroid或UICollectionViewiOS滑动卡顿如何优化”。我给一个能拿分的标准答题框架第一布局优化item布局层级尽量扁平避免多层嵌套第二图片优化使用图片加载框架的占位图、淡入淡出、缩略图机制避免加载原图后统一压缩第三数据优化分页加载配合预加载滑动时暂停加载不可见的item第四复用优化确认ViewHolder复用机制正常工作不要在getView中做耗时操作第五内存优化使用DiffUtil做局部刷新而不是notifyDataSetChanged全量刷新。图片加载这块Glide是Android面试题里的常客它在笔试中出现的形式通常是问“Glide的三级缓存机制是什么”。回答时讲清楚内存缓存LruCache→磁盘缓存DiskLruCache→网络加载读取顺序是从快到慢写入顺序是网络加载成功后先写内存再写磁盘。这个机制和浏览器的HTTP缓存有异曲同工之妙理解了一个另一个也就通了。58的笔试还考过“WebView性能优化”这个对App中嵌H5页面的业务场景非常关键。常见优化手段包括提前初始化WebView并复用内核开启硬件加速提升渲染速度通过离线包预加载H5资源使用addJavascriptInterface时注意泄漏和安全性以及用vConsole在移动端浏览器调试H5页面。4.2 移动端调试与vConsole使用技巧vConsole这个东西对经常做混合开发或者H5页面调试的同学来说应该不陌生。它本质上是一个移动端可用的前端调试面板作用和在PC浏览器里按F12打开DevTools类似但不需要连接数据线在手机浏览器里打开页面就能看到console日志、网络请求、本地存储等信息。笔试和项目面试中如果你提到自己用vConsole调试过线上问题会是一个非常亮眼的细节。具体场景是这样的App内嵌WebView访问H5页面用户反馈点按钮没反应但是在PC浏览器里一切正常。这种问题没法直接在PC上复现这时候你可以在HTML中引入vConsole的CDN在手机端打开页面后右下角会出现一个绿色按钮点击后就能看到报错信息。比如是某个接口返回了500或者某个JS方法抛了TypeError问题定位效率直接翻倍。给一个最简单的引入方式script srchttps://unpkg.com/vconsole/dist/vconsole.min.js/script script var vConsole new VConsole(); /script实际调试时我习惯只在测试环境引入vConsole并且用环境变量控制是否创建实例避免线上误开调试面板暴露敏感信息。如果你的页面是通过WebView加载的还可以通过原生代码注入这样连HTML都不用改。4.3 移动端网络优化与弱网处理移动端网络优化是后端移动端复合岗位特别喜欢出的场景题考察点在于你对网络请求完整链路的理解程度。答题可以从三个层面入手请求层、数据层、展示层。请求层核心是合理使用HTTP缓存。对于资讯列表这类更新频率高的接口用ETag做协商缓存每次请求带上If-None-Match命中304时直接复用本地缓存能显著降低流量消耗。数据层核心是本地缓存策略比如用SharedPreferences或Room数据库缓存最近一次成功拉取的数据App冷启动时先展示缓存内容再发起网络请求这就是“秒开”效果的底层原理。展示层核心是弱网兜底请求超时时间要合理设置比如10秒超时后给出友好的失败提示和重试按钮而不是一直转菊花。有一个笔试选择题我记得很清楚问“移动端网络请求超时时间设置多少比较合理”答案不是越短越好也不是越长越好而是结合业务场景设置可配置的超时时间——默认10秒弱网下自动调整为30秒。这种细节最能体现工程思维因为很多应届生的项目里根本没考虑过超时时间设置都是框架默认值。5. 编程题与场景设计题拿分的关键在于“思路外露”5.1 算法题类型与答题节奏编程题是笔试的硬骨头但好消息是58这道岗位的算法题难度并不高我回忆下来大概处于LeetCode中等偏下水平。高频类型包括字符串类的滑动窗口最长无重复子串、二叉树遍历层序遍历、最近公共祖先、链表操作反转链表、环形链表、简单的动态规划爬楼梯、打家劫舍以及拓扑排序类的题目。笔试时间100分钟建议编程题控制在35到40分钟内完成留出最后5到10分钟检查代码边界。如果一道题卡了15分钟没有思路果断跳到下一题先把能拿的分拿了。牛客网在线评测会在提交后立刻给出通过率如果你只通过了70%的用例大概率是边界条件没处理检查一下空数组、单个元素、数字溢出这类情况。我遇到的两道编程题大概是一道是“二叉树的最大深度”另一道是“合并两个有序数组”。都是LeetCode原题难度不高但注意题目要求空间复杂度为O(1)这意味着你不能另外new一个数组必须原地从后往前遍历合并。这种“要求藏在题目里”的细节就是拉开差距的地方。5.2 场景设计题示例信息流列表接口设计信息流接口设计题是58这场笔试里区分度最高的一道题。除了我之前讲的统一返回体和游标分页之外还要考虑几个工程问题第一接口如何保证数据一致性比如删除的资讯怎么从列表里消失第二并发场景下如何避免重复数据用户快速下拉时上一次请求还没返回下一次请求又发出去返回数据可能出现错乱需要前端做请求序号去重或加锁第三接口如何做权限控制资讯详情是否需要登录才能查看。我当时写的答案结构是这样的先说明接口请求参数cursor、limit、userId可选再说明服务端处理流程鉴权→参数校验→调用资讯服务→组装数据→返回然后说明响应结构最后补充异常处理token过期返回401、游标失效返回业务码提示重新加载。这套结构在面试里同样适用因为面试官追问的角度基本上就是这四块的延伸。还有一个容易被忽略的点接口版本管理。App发版节奏快后端接口结构可能会变常规做法是在URL中加入版本号比如/api/v1/feed、/api/v2/feed老版本App继续走老接口新版本App走新接口。这是后端开发里“兼容性优先”思维的体现我在笔试里也写了这个点。5.3 手写SQL与慢查询分析SQL题在58笔试里通常单独出一道给一张表让你统计结果难度介于“入门”和“入门偏上”之间。我当时遇到的是统计“每个城市下职位数量最多的前3个分类”需要用到窗口函数ROW_NUMBER()如果没接触过窗口函数这道题会卡住。窗口函数是MySQL 8.0才支持的功能如果笔试系统用的是5.7版本就需要用临时变量或者自连接来实现。建议备考时把ROW_NUMBER、RANK、DENSE_RANK这三个窗口函数的区别吃透以及GROUP BY和窗口函数在“取每组前几名”场景下的配合方式。这种SQL题在实际业务中非常常见58的招聘信息流里也经常有类似的统计需求。慢查询分析的简答题我前面已经提过这里再补充一个笔试答题模板第一步查看慢查询日志并确认是否开启第二步EXPLAIN看执行计划关注type字段ALL表示全表扫描ref/range表示走索引const表示主键或唯一索引等值查询第三步看是否出现filesort或using temporary第四步针对性优化——加索引、改写SQL、拆分大查询。把这四步写全基本就是一份能拿高分的答案。6. 实战复盘时间分配、答题顺序与避坑建议6.1 100分钟笔试时间怎么分配我根据自己的考场体验和周围同学的反馈整理了一份比较稳妥的时间分配方案。单选和多选一共25题建议控制在25分钟内平均每题1分钟碰到纠结超过2分钟的题先标记跳过3道简答题控制在30分钟内每道10分钟先写框架再补细节2道编程题控制在35分钟内最后留10分钟回头补跳过的选择题并检查代码边界。时间分配的关键是不要在一道选择题上死磕。笔试的容错率比你想的高20道单选全对和错3道的差距远小于一道编程题做出来和没做出来的差距。编程题才是分值的大头35%的权重直接决定你能否进入下一轮。6.2 常见失分点与避坑经验我总结了2023年这场笔试里考生最容易踩的几个坑覆盖不同题型。选择题方面多选题不是漏选就是多选。58的笔试明确写了“多选少选均不得分”所以拿不准的选项千万别选不要抱着“赌一把”的心态。比如问“哪些方法可以保证线程安全”如果只确定synchronized是对的volatile就坚决不选宁可丢一半分也不要全军覆没。简答题方面最大的坑是答题太口语化。笔试系统里简答题是纯文字输入有些人写“这个接口就先查一下然后返回前端”这种表述等于没写。答题一定要结构化分点、编号、给出具体的字段名和伪代码让阅卷人一眼看出你的思路是清晰的。编程题方面最大的坑是不写注释和不处理边界。牛客网判题只看通过率但代码整洁度会影响面试官在面试时对你的预设评价。我在代码开头简单写了思路注释结尾处理了空数组的情况两道题都拿了满分。还有一个容易被忽略的细节注意看题目要求的语言版本有些编译环境不支持Java 11之后的特性使用var等语法会直接编译报错。6.3 笔试后必须做的三件事复盘、补漏、写在简历里笔试结束不是结束而是下一轮面试备战的开始。我的习惯是趁自己对考题还有记忆立刻把题目复盘一遍哪些题是蒙的哪些题是真正不会的把不会的知识点整理成一个待查清单。比如我当时在“Redis过期策略”这道选择题上翻车了当天晚上就把惰性删除和定期删除的区别查了个清楚。另一个容易被忽略的动作是把笔试中暴露的薄弱环节补充到简历的“技能”里。比如笔试考了WebView优化而你恰好做过类似的项目那就把“基于WebView的混合开发与性能优化”写进项目描述笔试考了游标分页如果项目中用的是limit分页可以在面试前主动把项目改成游标分页——这种“让简历跟着笔试走”的策略能让你在面试时被问到的问题都在舒适区里。复盘时一定要把自己写的代码留档。有些笔试平台会在结束后关闭查看入口如果不及时保存编程题的解答过程就找不回来了。我一般会在提交前把代码复制到本地文本文件里并标注题目要求和我的解题思路这对后续面试时讲“你做过的算法题”很有帮助。6.4 这场笔试真正想筛选什么样的人最后再说点偏个人的体会。2023年58集团秋招后端移动端岗笔试从出题策略到分值分布都透露着一个明确信号它不想要只会刷题的人也不想要只会写业务代码的人而是想找真正理解“一个用户从点击页面到看到数据中间发生了什么”的人。后端移动端岗这个岗位名称本身就说明了问题——它要求你在后端接口设计和移动端性能优化之间自如切换。笔试中的每一道题本质上都在测试两件事一是你有没有一个完整的“HTTP请求生命周期”心智模型二是你能不能在这个模型上做出工程化的取舍。如果你平时写前端页面只知道调接口、写后端只知道返回数据没有思考过中间那一整条链路这场笔试可能会比较难受。准备这场笔试时我把“一个请求从App发出到渲染完成”这条链路从头到尾过了一遍DNS解析→建立TCP连接→发起HTTP请求→Nginx反向代理→后端鉴权→业务处理→查数据库→组装响应→移动端接收→Json解析→三级缓存写入→列表渲染→图片加载→弱网策略。每一个环节都准备了一个可讲的细节和一套优化的思路。这套准备方法帮我顺利通过了笔试也让我在之后的面试里受益良多。分享出来希望后来者少走一些弯路。 58集团秋招后端移动端岗笔试全解析：考点、题型与实战复盘
金九银十这个词在程序员校招圈里喊了得有七八年但真到了每年九、十月份你才会发现它一点没夸张。牛客网上刷屏的笔试求助帖、脉脉上“有没有人收到面试通知”的追问、宿舍楼道里抱着电脑做在线测评的室友这些都是秋招季的标配画面。2023年58集团秋招后端移动端岗笔试是我当年印象很深的一场。先说结论这个岗位的笔试不走寻常路它既不像纯后端岗那样把算法题堆到让人头皮发麻也不像纯客户端岗那样疯狂追问Android源码细节而是把后端主力考点和移动端核心素养揉在一起考察你是否具备从服务端到客户端整条链路的全局视野。58同城的业务特点是信息分发招聘、房产、二手车这些典型的分类信息场景后端要扛住高并发检索和海量数据写入移动端要承接复杂列表、图片加载和IM消息推送所以笔试出题非常看重“业务落地能力”。这篇文章我会把这场笔试涉及的题型分布、核心考点、答题思路和实战技巧完整拆一遍所有内容结合我当时在牛客网看过的真题回忆、同行交流以及同类岗位的通用考法整理。无论你是准备投递后端岗还是移动端岗这套复盘逻辑都能直接用。1. 笔试全貌一场“后端为主、移动端为辅”的复合能力测验1.1 岗位定位与笔试风格分析后端移动端岗这个组合在后端和客户端岗位序列里都算一个比较特殊的存在。很多没接触过的同学会疑惑这到底是偏后端还是偏客户端我笔试前专门查过58同城的岗位描述它其实是想找一类“全链路工程师”——既能写服务端接口也能理解移动端如何消费这些接口在前后端联调、接口设计、性能优化这些环节能自己闭环。这就决定了笔试的命题风格不会只考某一端而是把两端串起来考。比如给你一个接口场景让你分析服务端该怎么设计然后又会追问移动端拿到数据后如何渲染、如何做缓存、弱网下怎么处理。这种“一条链路考到底”的方式在58的笔试里体现得特别明显。1.2 题型分布与分值结构根据2023年秋招实际笔试情况来看58的后端移动端岗笔试用的是牛客网在线评测系统整体时长100分钟题量和分值大致如下题型题量分值占比特点单项选择题20题30%计算机基础为主覆盖面广多项选择题5题15%易错点集中多选少选均不得分简答题3题20%偏场景设计考工程落地思维编程题2题35%算法为主难度LeetCode中等偏下这个分值分布很有讲究。算法题只占35%意味着它不想用算法题卡死所有人而是想借选择题和简答题筛出真正有工程经验积累的人。所以如果你算法能力一般但项目经验和基础功扎实这场笔试是很有机会突围的。牛客网的笔试系统支持本地IDE调试编程题只需要把最终代码粘贴到网页里提交所以平时习惯用IDEA写代码的同学不需要担心在线编辑器难用。1.3 高频考点地图把2023年这场笔试和同批次其他公司比如美团、京东、拼多多的考题放在一起对比你会发现58的出题重点有明显的业务导向。我当时整理了一张考点分布表覆盖了大概90%的考题方向现在翻出来看依然很有参考价值考察方向具体知识点出现频率计算机网络TCP/IP、HTTP状态码、缓存机制极高Java基础集合框架、并发编程、JVM内存模型极高数据库SQL编写、索引优化、事务隔离级别高Spring生态IOC、AOP、Spring Boot自动配置中高前后端交互RESTful接口、JSON、跨域、鉴权中高移动端基础列表优化、图片加载、网络请求中等算法与数据结构二叉树、字符串、动态规划、堆栈高这张表其实是很多互联网公司后端岗位笔试的“最大公约数”但58的特色在于移动端知识占比明显比纯后端岗高而且问法很落地。比如它不会直接问你“Android的RecyclerView原理是什么”而是给一个具体场景——“信息流滑动卡顿请分析可能原因并给出优化方案”。这种问法更考验候选人在真实业务里解决问题的能力光背八股文是答不好的。提示58集团后端移动端岗的笔试真正的难点不是题目本身有多深而是知识面跨度大。你需要在有限时间内从前端跨域调到后端接口设计再跳到移动端渲染优化脑回路切换跟不上就会慌。建议备考时把“前后端分离架构下的完整请求链路”作为主线去复习。2. 核心知识点逐项拆解计算机基础与Java后端必备2.1 计算机网络从TCP握手到HTTP缓存机制网络这块在58笔试里的考法偏应用型很少直接让你默写“三次握手的过程”而是喜欢换个场景问你“为什么连接建立需要三次握手断开却需要四次”。我当时遇到的一道选择题就是这个思路四个选项里有两个看着都对但只有一个是把“防止历史连接请求到达服务端造成资源浪费”这个核心原因讲清楚的。TCP三次握手可以类比成两个人打电话确认双方都能听能说A先问B“你能听到吗”B收到后回复“我能听到你能听到我吗”A再回一句“我能听到”这样双方才确认通信链路可用。之所以要三次而不是两次核心是为了防止客户端发出的失效连接请求突然到达服务端导致服务端白白建立一条没有意义的连接。如果只有两次握手服务端无法确认客户端的接收能力是否正常。HTTP相关考点同样是重头戏。状态码这块我建议重点区分301永久重定向和302临时重定向、304协商缓存命中、401未认证和403无权限这三组几乎每年必考。缓存机制也是高频题强缓存的Expires和Cache-Control优先级怎么判断协商缓存的ETag和Last-Modified存在什么区别如果要求“刷新页面时不走缓存”应该怎么做——这些细节在58这类信息流业务里非常实用因为移动端App大量依赖缓存来提升加载速度。2.2 Java基础集合、并发与JVM的经典考点Java在58后端技术栈里占主导地位笔试选择题里Java基础的分量很重。HashMap是万年不变的考点但我那次遇到的不是“HashMap底层数据结构”这种入门题而是问“JDK 1.8中HashMap在什么条件下会从链表转为红黑树”以及“为什么阈值是8”。这两个问题就需要你真正读过源码才能答得准——链表转红黑树的触发条件是链表长度超过8且数组长度大于等于64设计成8的原因是根据泊松分布在负载因子0.75的情况下链表长度达到8的概率极低属于一种概率上的安全阈值。并发编程也是高频区块。synchronized和ReentrantLock的区别、volatile的可见性和有序性原理、ConcurrentHashMap在JDK 1.8为什么放弃分段锁改成CAS加synchronized锁头节点——这些是出现频率最高的三个问题。我当时在简答题里遇到一个场景“多个线程同时对一个计数器进行自增操作如何保证线程安全且性能最优”这其实就是在考察AtomicLong和LongAdder的取舍。在低并发场景下AtomicLong的CAS自旋足够但在高并发下LongAdder采用分段累加再汇总的方式性能优势非常明显——这和ConcurrentHashMap放弃分段锁的思路殊途同归。JVM内存模型和垃圾回收主要出现在选择题。需要重点关注的是堆内存中年轻代和老年代的比例默认是1比2、对象什么时候从年轻代晋升到老年代年龄达到15或大对象直接进入老年代、Minor GC和Full GC的触发条件。58的笔试很少考JVM调参这种偏运维的题更多是考察你对内存区域划分的理解是否清晰。2.3 数据库与索引SQL题和慢查询优化的答题思路数据库这块58笔试的SQL题通常比较贴近业务会给你一张类似“用户职位收藏表”的表结构让你统计数据。常见考法包括分组聚合GROUP BY HAVING、多表关联JOIN、子查询去重、日期函数处理。编程题里如果有SQL的话一般占一道简答或选择不会单独出大分值的题但SQL写不写得对直接影响面试官对你的印象分。索引优化是选择题和简答题的共同热点。我印象很深的一道题是“有一个订单表查询条件为status和create_time如何建立索引最高效”标准答案是建立组合索引status, create_time把等值查询的字段放前面范围查询的字段放后面。这背后的原理是B树索引的匹配规则——最左前缀原则。如果反过来建立create_time, status的索引那么在查询status为某个值时create_time的等值条件就无法充分利用索引的有序性。慢查询优化是58这类信息分发业务非常关心的问题。简答题如果涉及数据库很大概率会问“一条SQL执行很慢你如何排查”。答题思路建议从外到内先用EXPLAIN看执行计划确认是否走了索引再看是否因为深分页LIMIT offset大偏移量导致扫描大量无用数据然后考虑是否需要对高频查询字段增加索引或冗余字段最后才是考虑缓存Redis挡流量。笔试时把这条链路写清楚比背几个索引口诀有用得多因为面试官能看出你真的处理过线上慢查询问题。3. 前后端链路与Spring生态把“分离”这件事讲透3.1 Spring Boot核心原理与IOC/AOP答题框架Spring Boot在58后端笔试里的地位相当于是“默认你会”。它不会直接问你“Spring Boot是什么”而是通过让你分析某个配置或组件的工作原理来间接检验你是否真的用过。IOC控制反转和AOP面向切面编程是绕不开的两个核心概念。我后来复盘时总结了一个比较清楚的答题框架IOC就是把对象的创建和依赖关系的维护从“自己new”交给“Spring容器管理”。你可以类比成吃饭——不用自己种菜、洗菜、炒菜而是去餐厅点菜厨师容器把做好的菜端给你。这么做最大的好处是解耦代码里不出现new关键字替换实现类时不需要改动调用方代码。AOP则是在不修改原有代码的情况下给方法统一添加日志、事务、权限校验等逻辑——就像商场里的自动感应门你不需要改造墙体结构只需要在门上装一个感应器进出时自动开门。Spring Boot自动配置也是高频考点。它本质上依赖EnableAutoConfiguration注解和spring.factories/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件启动时通过ConditionalOnClass、ConditionalOnMissingBean等条件注解按需装配bean。笔试里最常见的问法是“如何覆盖Spring Boot的默认配置”答案是在配置文件中显式声明bean或者使用Primary注解这比知道自动配置的源码更实用。3.2 前后端分离架构下的接口设计与数据格式约定58的笔试非常喜欢出“接口设计”类题目这大概是后端移动端岗的特色之一。我遇到的一道简答题是“设计一个App资讯信息流的列表接口需要支持分页加载和下拉刷新请写出请求参数、响应结构和异常处理方案。”这道题看着简单想拿高分并不容易。响应结构我建议直接套用统一返回体设计这是前后端分离项目里最约定俗成的做法。类似这样{ code: 0, message: success, data: { list: [ { id: 1024, title: 标题, coverUrl: https://example.com/cover.png, publishTime: 1695000000000 } ], hasMore: true, nextCursor: 1695000000000_1024 } }code为0表示成功非0表示业务异常data里不直接返回total而是返回hasMore和nextCursor这样能支撑移动端的“上拉加载更多”和“判断是否还有下一页”。分页方式建议用游标分页而不是传统的page/size。原因是信息流场景下用户会持续下拉翻页如果用limit offset做深分页页数越深MySQL扫描的数据越多性能急剧下降游标分页以最后一条记录的排序字段作为下次查询的起点理论上可以一直翻下去而不变慢。接口设计这里还有一个小细节很考验工程经验必须约定好时间格式。推荐用毫秒级时间戳long类型而不是字符串因为字符串在跨时区、跨语言序列化时容易出现格式不一致的问题。我在笔试中把这一点也写了进去后来面试时面试官特意提了一句说这个细节很加分。3.3 跨域问题的本质与四种解法跨域问题是前后端分离项目里绕不开的坎也是我当年笔试选择题和简答题都碰到过的考点。它的本质是浏览器的同源策略——协议、域名、端口三者只要有一个不一致浏览器就会拦截跨域请求的响应。这里注意请求通常是发出去了服务端也正常处理了只是响应被浏览器拦下来了。笔试能拿分的解法有四种第一JSONP利用script标签不受同源策略限制的特性只支持GET请求现在用得越来越少第二CORS后端在响应头加Access-Control-Allow-Origin等字段这是最标准的解决方案第三反向代理在Nginx或开发服务器里配置proxy_pass让前端请求同源的代理地址由代理转发到真实后端服务这是前后端分离项目开发环境里最常用的方案第四服务端渲染或网关层处理。我当时在Vue项目中配置过Vite或webpack的proxy代理原理就是第三种方案。平时debug时可以打开浏览器DevTools的Network面板如果看到“Access-Control-Allow-Origin”相关的报错先别急着怀疑后端检查一下代理配置是否正确——这是前后端联调踩坑率最高的一个环节。注意很多应届生在笔试里写跨域问题时只知道一个CORS如果你的答案里能把代理方式也讲清楚并且说明“CORS适合生产环境、代理适合开发环境”面试官会明显感觉你有真实联调经验。3.4 前后端分离项目实战经验如何转化为笔试答案58的笔试虽然没有直接让你写项目但简答和选择题里很多答案其实都来自你在实际项目中的积累。我备考的时候发现一个规律凡是在简历上写了“前后端分离项目”的同学笔试里关于接口联调、鉴权、部署的题目正确率普遍更高。前后端分离的核心流程是这样的后端写好接口文档Swagger/YApi前端根据文档进行页面开发联调阶段通过Mock数据模拟接口返回后端接口就绪后切换成真实地址开发完成后把前端构建产物dist目录部署到Nginx后端服务部署到服务器由Nginx统一处理静态资源请求并反向代理API请求。这一套流程在笔试中至少能用来回答三类问题跨域怎么解决Nginx反向代理、部署架构是什么样Nginx Spring Boot Jar包、为什么前端页面能访问后端数据同源策略下的代理转发。我在笔试简答题里就是按照“后端如何组织代码、前端如何调用、nginx如何分发”这个思路去答的虽然没有一个标准的“正确答案”但阅卷人一看就知道你确实独立做过完整项目。所以如果你现在还有时间准备强烈建议手写一个最简单的Spring Boot Vue前后端分离项目不需要复杂业务逻辑能把用户登录和列表展示贯通即可含金量远超刷十套题。4. 移动端方向考点性能优化与调试实操4.1 移动端列表渲染与图片加载优化58集团的App业务中有大量feed流场景列表性能直接决定用户体验。笔试中移动端方向的题目几乎都围绕性能优化展开最常见的是“RecyclerViewAndroid或UICollectionViewiOS滑动卡顿如何优化”。我给一个能拿分的标准答题框架第一布局优化item布局层级尽量扁平避免多层嵌套第二图片优化使用图片加载框架的占位图、淡入淡出、缩略图机制避免加载原图后统一压缩第三数据优化分页加载配合预加载滑动时暂停加载不可见的item第四复用优化确认ViewHolder复用机制正常工作不要在getView中做耗时操作第五内存优化使用DiffUtil做局部刷新而不是notifyDataSetChanged全量刷新。图片加载这块Glide是Android面试题里的常客它在笔试中出现的形式通常是问“Glide的三级缓存机制是什么”。回答时讲清楚内存缓存LruCache→磁盘缓存DiskLruCache→网络加载读取顺序是从快到慢写入顺序是网络加载成功后先写内存再写磁盘。这个机制和浏览器的HTTP缓存有异曲同工之妙理解了一个另一个也就通了。58的笔试还考过“WebView性能优化”这个对App中嵌H5页面的业务场景非常关键。常见优化手段包括提前初始化WebView并复用内核开启硬件加速提升渲染速度通过离线包预加载H5资源使用addJavascriptInterface时注意泄漏和安全性以及用vConsole在移动端浏览器调试H5页面。4.2 移动端调试与vConsole使用技巧vConsole这个东西对经常做混合开发或者H5页面调试的同学来说应该不陌生。它本质上是一个移动端可用的前端调试面板作用和在PC浏览器里按F12打开DevTools类似但不需要连接数据线在手机浏览器里打开页面就能看到console日志、网络请求、本地存储等信息。笔试和项目面试中如果你提到自己用vConsole调试过线上问题会是一个非常亮眼的细节。具体场景是这样的App内嵌WebView访问H5页面用户反馈点按钮没反应但是在PC浏览器里一切正常。这种问题没法直接在PC上复现这时候你可以在HTML中引入vConsole的CDN在手机端打开页面后右下角会出现一个绿色按钮点击后就能看到报错信息。比如是某个接口返回了500或者某个JS方法抛了TypeError问题定位效率直接翻倍。给一个最简单的引入方式script srchttps://unpkg.com/vconsole/dist/vconsole.min.js/script script var vConsole new VConsole(); /script实际调试时我习惯只在测试环境引入vConsole并且用环境变量控制是否创建实例避免线上误开调试面板暴露敏感信息。如果你的页面是通过WebView加载的还可以通过原生代码注入这样连HTML都不用改。4.3 移动端网络优化与弱网处理移动端网络优化是后端移动端复合岗位特别喜欢出的场景题考察点在于你对网络请求完整链路的理解程度。答题可以从三个层面入手请求层、数据层、展示层。请求层核心是合理使用HTTP缓存。对于资讯列表这类更新频率高的接口用ETag做协商缓存每次请求带上If-None-Match命中304时直接复用本地缓存能显著降低流量消耗。数据层核心是本地缓存策略比如用SharedPreferences或Room数据库缓存最近一次成功拉取的数据App冷启动时先展示缓存内容再发起网络请求这就是“秒开”效果的底层原理。展示层核心是弱网兜底请求超时时间要合理设置比如10秒超时后给出友好的失败提示和重试按钮而不是一直转菊花。有一个笔试选择题我记得很清楚问“移动端网络请求超时时间设置多少比较合理”答案不是越短越好也不是越长越好而是结合业务场景设置可配置的超时时间——默认10秒弱网下自动调整为30秒。这种细节最能体现工程思维因为很多应届生的项目里根本没考虑过超时时间设置都是框架默认值。5. 编程题与场景设计题拿分的关键在于“思路外露”5.1 算法题类型与答题节奏编程题是笔试的硬骨头但好消息是58这道岗位的算法题难度并不高我回忆下来大概处于LeetCode中等偏下水平。高频类型包括字符串类的滑动窗口最长无重复子串、二叉树遍历层序遍历、最近公共祖先、链表操作反转链表、环形链表、简单的动态规划爬楼梯、打家劫舍以及拓扑排序类的题目。笔试时间100分钟建议编程题控制在35到40分钟内完成留出最后5到10分钟检查代码边界。如果一道题卡了15分钟没有思路果断跳到下一题先把能拿的分拿了。牛客网在线评测会在提交后立刻给出通过率如果你只通过了70%的用例大概率是边界条件没处理检查一下空数组、单个元素、数字溢出这类情况。我遇到的两道编程题大概是一道是“二叉树的最大深度”另一道是“合并两个有序数组”。都是LeetCode原题难度不高但注意题目要求空间复杂度为O(1)这意味着你不能另外new一个数组必须原地从后往前遍历合并。这种“要求藏在题目里”的细节就是拉开差距的地方。5.2 场景设计题示例信息流列表接口设计信息流接口设计题是58这场笔试里区分度最高的一道题。除了我之前讲的统一返回体和游标分页之外还要考虑几个工程问题第一接口如何保证数据一致性比如删除的资讯怎么从列表里消失第二并发场景下如何避免重复数据用户快速下拉时上一次请求还没返回下一次请求又发出去返回数据可能出现错乱需要前端做请求序号去重或加锁第三接口如何做权限控制资讯详情是否需要登录才能查看。我当时写的答案结构是这样的先说明接口请求参数cursor、limit、userId可选再说明服务端处理流程鉴权→参数校验→调用资讯服务→组装数据→返回然后说明响应结构最后补充异常处理token过期返回401、游标失效返回业务码提示重新加载。这套结构在面试里同样适用因为面试官追问的角度基本上就是这四块的延伸。还有一个容易被忽略的点接口版本管理。App发版节奏快后端接口结构可能会变常规做法是在URL中加入版本号比如/api/v1/feed、/api/v2/feed老版本App继续走老接口新版本App走新接口。这是后端开发里“兼容性优先”思维的体现我在笔试里也写了这个点。5.3 手写SQL与慢查询分析SQL题在58笔试里通常单独出一道给一张表让你统计结果难度介于“入门”和“入门偏上”之间。我当时遇到的是统计“每个城市下职位数量最多的前3个分类”需要用到窗口函数ROW_NUMBER()如果没接触过窗口函数这道题会卡住。窗口函数是MySQL 8.0才支持的功能如果笔试系统用的是5.7版本就需要用临时变量或者自连接来实现。建议备考时把ROW_NUMBER、RANK、DENSE_RANK这三个窗口函数的区别吃透以及GROUP BY和窗口函数在“取每组前几名”场景下的配合方式。这种SQL题在实际业务中非常常见58的招聘信息流里也经常有类似的统计需求。慢查询分析的简答题我前面已经提过这里再补充一个笔试答题模板第一步查看慢查询日志并确认是否开启第二步EXPLAIN看执行计划关注type字段ALL表示全表扫描ref/range表示走索引const表示主键或唯一索引等值查询第三步看是否出现filesort或using temporary第四步针对性优化——加索引、改写SQL、拆分大查询。把这四步写全基本就是一份能拿高分的答案。6. 实战复盘时间分配、答题顺序与避坑建议6.1 100分钟笔试时间怎么分配我根据自己的考场体验和周围同学的反馈整理了一份比较稳妥的时间分配方案。单选和多选一共25题建议控制在25分钟内平均每题1分钟碰到纠结超过2分钟的题先标记跳过3道简答题控制在30分钟内每道10分钟先写框架再补细节2道编程题控制在35分钟内最后留10分钟回头补跳过的选择题并检查代码边界。时间分配的关键是不要在一道选择题上死磕。笔试的容错率比你想的高20道单选全对和错3道的差距远小于一道编程题做出来和没做出来的差距。编程题才是分值的大头35%的权重直接决定你能否进入下一轮。6.2 常见失分点与避坑经验我总结了2023年这场笔试里考生最容易踩的几个坑覆盖不同题型。选择题方面多选题不是漏选就是多选。58的笔试明确写了“多选少选均不得分”所以拿不准的选项千万别选不要抱着“赌一把”的心态。比如问“哪些方法可以保证线程安全”如果只确定synchronized是对的volatile就坚决不选宁可丢一半分也不要全军覆没。简答题方面最大的坑是答题太口语化。笔试系统里简答题是纯文字输入有些人写“这个接口就先查一下然后返回前端”这种表述等于没写。答题一定要结构化分点、编号、给出具体的字段名和伪代码让阅卷人一眼看出你的思路是清晰的。编程题方面最大的坑是不写注释和不处理边界。牛客网判题只看通过率但代码整洁度会影响面试官在面试时对你的预设评价。我在代码开头简单写了思路注释结尾处理了空数组的情况两道题都拿了满分。还有一个容易被忽略的细节注意看题目要求的语言版本有些编译环境不支持Java 11之后的特性使用var等语法会直接编译报错。6.3 笔试后必须做的三件事复盘、补漏、写在简历里笔试结束不是结束而是下一轮面试备战的开始。我的习惯是趁自己对考题还有记忆立刻把题目复盘一遍哪些题是蒙的哪些题是真正不会的把不会的知识点整理成一个待查清单。比如我当时在“Redis过期策略”这道选择题上翻车了当天晚上就把惰性删除和定期删除的区别查了个清楚。另一个容易被忽略的动作是把笔试中暴露的薄弱环节补充到简历的“技能”里。比如笔试考了WebView优化而你恰好做过类似的项目那就把“基于WebView的混合开发与性能优化”写进项目描述笔试考了游标分页如果项目中用的是limit分页可以在面试前主动把项目改成游标分页——这种“让简历跟着笔试走”的策略能让你在面试时被问到的问题都在舒适区里。复盘时一定要把自己写的代码留档。有些笔试平台会在结束后关闭查看入口如果不及时保存编程题的解答过程就找不回来了。我一般会在提交前把代码复制到本地文本文件里并标注题目要求和我的解题思路这对后续面试时讲“你做过的算法题”很有帮助。6.4 这场笔试真正想筛选什么样的人最后再说点偏个人的体会。2023年58集团秋招后端移动端岗笔试从出题策略到分值分布都透露着一个明确信号它不想要只会刷题的人也不想要只会写业务代码的人而是想找真正理解“一个用户从点击页面到看到数据中间发生了什么”的人。后端移动端岗这个岗位名称本身就说明了问题——它要求你在后端接口设计和移动端性能优化之间自如切换。笔试中的每一道题本质上都在测试两件事一是你有没有一个完整的“HTTP请求生命周期”心智模型二是你能不能在这个模型上做出工程化的取舍。如果你平时写前端页面只知道调接口、写后端只知道返回数据没有思考过中间那一整条链路这场笔试可能会比较难受。准备这场笔试时我把“一个请求从App发出到渲染完成”这条链路从头到尾过了一遍DNS解析→建立TCP连接→发起HTTP请求→Nginx反向代理→后端鉴权→业务处理→查数据库→组装响应→移动端接收→Json解析→三级缓存写入→列表渲染→图片加载→弱网策略。每一个环节都准备了一个可讲的细节和一套优化的思路。这套准备方法帮我顺利通过了笔试也让我在之后的面试里受益良多。分享出来希望后来者少走一些弯路。