1. 面试场景题到底在考什么这些年我一直在做技术面试官也帮不少朋友做过模拟面试辅导。有一个明显的感受是很多候选人在基础知识上背得滚瓜烂熟八股文张口就来但一到场景题就卡壳。为什么会这样因为场景题考察的根本不是“你记住了什么”而是“你在真实世界里怎么思考问题”。所谓“面试场景题”通常是指面试官给出一个相对开放的业务需求或者系统问题让你现场分析、设计、给出方案。它可能是“如何设计一个短链接系统”可能是“线上接口突然变慢你怎么排查”也可能是“让你从零搭一个推荐系统的骨架”。这类题目没有标准答案但有一套被广泛认可的答题框架和思考路径。我整理过很多场面试记录发现场景题挂掉的人大多不是能力不行而是解题方式不对。有的人上来就写代码有的人堆砌一堆高大上的名词还有的人直接把课本上的定义背一遍。这些做法都很吃亏。真正拉开差距的是你有没有一套结构化的拆解思路能不能在有限时间内把一个问题从模糊变成清晰从抽象落到具体。这篇文章我想把自己这些年总结的面试场景题答题方法论、常见题型的拆解思路、以及一些实战中踩过的坑完整地分享出来。内容不针对某一家公司而是通用的方法论适合正在准备面试的同学也适合那些想提升自己系统设计能力和问题排查能力的技术人。2. 答题框架场景题的通用解题骨架2.1 先搞清楚题目到底在问什么很多人在场景题上翻车第一关就输在审题。我见过太多候选人题目还没听完就开始抢答结果答了半天面试官轻轻一句“我不是这个意思”场面瞬间尴尬。场景题通常信息密度很低可能就一两句话“假设你现在要设计一个外卖配送调度系统你会怎么做”但这背后其实藏着很多隐含要求。你需要先和面试官确认几个关键点系统的用户规模大概多少是实时性要求高还是数据准确性要求高有没有预算或硬件限制是要完整方案还是只关注某个模块这一步叫做“澄清需求”。表面上是问问题实际上是在展示你的思维严谨性。面试官不会因为你多问几句就扣分反而会觉得你是一个靠谱的工程师。我建议至少确认三件事用户量和数据量级、核心功能边界、性能或一致性要求。这三个维度基本决定后续所有设计选择。比如“短链接系统”如果你不问量级可能会设计出一套基于数据库自增ID的方案。但当面试官告诉你QPS要到十万级时你就得考虑发号器、缓存、布隆过滤器这些东西。同样是短链接量级不同方案天差地别。所以第一优先级永远是澄清需求。2.2 从“功能”和“非功能”两个维度拆解澄清完需求之后接下来要做的就是把一个笼统的问题拆成可讨论的子问题。我习惯用两个维度来拆功能需求和非功能需求。功能需求指的是系统必须完成的具体事情。以“外卖配送调度系统”为例功能需求可能包括订单接入、骑手派单、路线规划、状态跟踪、异常处理。非功能需求则包括性能延迟、吞吐量、可用性宕机能不能扛住、一致性订单状态会不会错、可扩展性订单量涨十倍怎么办、安全性用户信息怎么保护。这一步的目的是向面试官展示你不是在凭感觉设计而是有章法地在做需求分析。你可以一边拆一边和面试官确认“我理解的核心功能是这样您看对吗”这种互动会让面试官更愿意和你聊下去。拆解完之后最好能给一个优先级排序。因为任何系统都不可能一开始就完美兼顾所有指标。比如一个IM系统消息的实时送达可能比消息的永久存储更重要一个支付系统数据的一致性可能比可用性更关键。你愿意做取舍并且能把取舍的理由说清楚这本身就是面试官想看到的工程师素养。2.3 给出方案时要有层次感我见过一些候选人一上来就画架构图数据库、缓存、消息队列、微服务全给安排上。这样做的风险是你根本无法在短时间内把所有细节想清楚而且一旦被追问很容易露馅。更好的做法是分层递进先给出一个最小可行方案再逐步优化。最小可行方案通常是单机版用一个数据库加一个应用服务就能搞定。然后你再说“如果量级上来我们可以引入缓存来减轻数据库压力”“如果单机扛不住我们可以水平扩展把无状态服务部署多份数据库做读写分离”。每加一层你都要能解释清楚它解决了什么问题带来了什么新的复杂度。这种“先简后繁”的讲法非常讨喜。它证明了你有全局视角不会一上来就过度设计同时每一层的引入逻辑都很清晰面试官跟进起来也不累。我自己面试别人时最反感的就是候选人把一堆中间件名字堆在那里问他为什么要用他说“大家都这么用的”。这种答案没有任何信息量。3. 高频场景题类型逐一拆解3.1 系统设计类短链接系统设计短链接系统可以说是场景题中的经典款几乎每隔几场面试就会出现。它看起来简单仔细挖起来却很深。核心功能就是把一个长URL转换成一个短URL用户访问短URL时能重定向到原地址同时还要能统计点击量。答题的第一步还是澄清量级。假设面试官说日均生成一亿条短链接QPS大概一千读QPS是写的一百倍。这个量级意味着什么意味着生成短链接的并发压力不大但访问短链接的流量很高所以缓存是必须的。另外一亿条数据不是一个小数量如果用UUID直接当短码那存储和索引都会很吃力。短链接生成的核心是“发号器”。最经典的做法是用一个全局自增ID然后把十进制ID转成62进制大小写字母加数字得到一个六到七位的短码。这个方案的好处是短码唯一、生成简单、不需要查重。坏处是ID是递增的别人可以通过短码反推出生成数量存在一定的安全问题。如果不想让ID可预测可以在发号器里加入一个随机偏移量或者用雪花算法生成ID然后做一次混淆。短链接访问链路一般是这样用户点击短链接请求打到网关网关先去查缓存命中就直接返回原始URL并返回301/302重定向缓存没命中再查数据库查到后回填缓存。这里有个细节重定向用301还是302301是永久重定向浏览器会缓存结果后续访问不再请求我们的服务器这样服务端统计点击量会不准302是临时重定向每次都会请求服务器虽然会多一点延迟但能准确统计点击次数。大多数短链接系统选择302就是因为需要统计。这个题目还可以继续深入如果发号器单机性能不够怎么办那就用分布式发号器比如一段区间一段区间地分配每个节点生成一段范围内的ID用完了再去申请下一段。还可以用Redis的INCR命令来生成自增ID配合持久化保证不重复。讲到这一层面试官基本就能确认你是真的理解分布式系统的常见套路了。3.2 系统设计类即时消息系统架构即时消息IM系统是另一种高频场景题。它和短链接系统最大的不同在于短链接是典型的高读低写而IM是读写都很频繁而且对实时性要求很高。做IM设计时我习惯先分清楚“在线消息”和“离线消息”。在线消息可以走长连接直接推送离线消息则需要存储在服务端等用户上线后再拉取。这两条链路对后端的要求完全不一样。在线消息的核心是长连接管理。客户端和服务器之间需要维持一个TCP长连接常见的方案是WebSocket。服务端需要维护一张“用户ID到连接”的映射表当用户发消息时服务端根据接收方ID找到对应的连接然后推过去。这里马上会碰到一个问题用户可能从多个设备登录或者连接会断。所以映射表不能只存一个连接要存一个连接列表并且要有心跳检测和断线重连机制。如果用户量很大单机维护不了所有连接怎么办这时候就要引入“连接网关”集群每个用户随机连到某一台网关机器。发消息时你需要知道接收方在哪台网关上。一般会引入一个路由层保存用户ID和网关节点的映射关系消息先到路由层路由层找到目标网关再往下推送。这就是IM系统最基础的架构骨架。离线消息的存储相对简单可以用数据库或消息队列把消息暂存起来等用户上线后进行拉取。但这里有一个一致性问题消息到底是推送给所有在线设备还是等设备主动拉取两种模式各有优劣推送模式实时性好但服务端压力大拉取模式服务端压力小但可能延迟。很多系统采用“推送拉取补偿”的方式正常情况下推送如果发现有消息没送达客户端可以定期主动拉取一次保证不丢消息。这个题目能挖的还很多比如消息的时序怎么保证、多端在线怎么同步已读状态、图片视频这类大消息要不要走独立通道。每展开一个点都能体现你的设计经验。我建议准备IM场景题时至少围绕“连接管理、消息路由、离线存储、多端同步”这四个点整理一套自己的话术。3.3 排查类场景题线上接口突然变慢怎么办排查类场景题和设计类不一样它不要求你从零搭系统而是给你一个“事故现场”考验你临场分析和快速定位问题的能力。这类题在高级工程师面试中特别常见。典型的问法是“线上有一个接口平时响应时间50毫秒今天突然变成5秒你怎么排查”这个问题没有标准剧本但有一套高效的三板斧先确认影响范围再定位瓶颈层级最后结合监控数据收敛。确认影响范围是第一步。你需要问自己是所有接口都慢还是只有这个接口慢是所有用户都慢还是部分用户慢是持续性的还是间歇性的这几个问题能帮你快速缩小排查范围。如果所有接口都慢那大概率是基础设施或依赖服务出了问题如果只有一个接口慢就要往这个接口本身去分析。接下来看瓶颈层级。一个请求从上到下会经过客户端、网络、网关、应用服务、数据库、第三方依赖。你可以按“由近及远”或“由外到内”的思路逐层排查。先用工具确认是不是网络问题再看服务端日志有没有超时记录然后看数据库的慢查询日志最后看外部依赖接口的响应时间。这里有一个我特别想强调的点很多新手一上来就翻代码试图通过读代码找到性能问题。这其实很低效。正确的做法是先看监控和指标用数据定位再去看代码。比如你发现数据库CPU飙升到90%慢查询日志里出现某条SQL这时候你再回到代码里看这条SQL的执行逻辑就很有针对性了。反过来没有任何数据支撑就去读代码大概率是浪费时间。除了CPU、内存、磁盘、网络这些常规指标还要关注“长尾延迟”。平均值往往具有欺骗性可能99%的请求都是快的但1%的请求慢到超时。对这种场景要看P95、P99分位延迟并找到那批慢请求的共同特征比如是不是特定用户、特定参数、特定时间点。我处理过一个真实案例最后定位到是因为某个用户上传了一张超大图片触发了图片压缩的CPU密集型操作导致该线程阻塞继而拖慢了整个接口的线程池。这种问题如果只看平均值永远发现不了。3.4 扩展类场景题海量数据中如何找到Top K海量数据题目属于算法和系统设计的交叉领域也是面试官很爱用来拉开区分度的一类题。题目通常是这样“有一个文件里面有几十亿个数内存只有几百MB怎么找出最大的100个数”这道题看起来像Top K问题的变体但因为数据规模和内存限制不能直接用排序加截断的方式搞定。标准的解法是用堆维护一个大小为100的小顶堆遍历数据如果当前数大于堆顶就把堆顶弹出把当前数插入堆。这样遍历完整个文件后堆里的100个数就是最大的100个。小顶堆的时间复杂度是O(N log K)K100时基本可以视为O(N)空间占用只有K个元素完全可控。如果数据不能一次性加载到内存那就要分治。把大文件切分成多个小文件每个小文件能在内存中处理分别求出每个文件的Top 100最后再对所有Top 100做一次归并。这一套思路叫做“分而治之”也是MapReduce的思想雏形。面试时如果你能主动提到“这和MapReduce中的Map端局部聚合、Reduce端全局聚合是同一个思路”面试官通常会眼前一亮。另一个常见变体是“统计海量数据中出现频率最高的K个词”。这时候堆本身解决不了出现频率的统计问题需要先用哈希映射把每个词的出现次数计算出来。数据量很大时哈希映射的内存占用也可能超限那就要用哈希分片对每个词做哈希取模后分到不同的机器或文件中每个分片单独统计频率最后再做全局归并。这个思路和分布式的Shuffle过程非常像本质上都是在解决“数据分散内存不够需要并行归并”的问题。拿到这类题目时我建议先说清楚你的思路链路先明确内存限制和数据量级然后提出用堆作为核心数据结构如果内存不够再引入分治最后补充分治的细节。这样的表达本身就是一种“设计能力”的展示比你直接甩一个解法要强得多。4. 从“会答题”到“会思考”场景题背后的思维模型4.1 容量估算数字敏感度是基本功场景题里经常需要你给出一些数据量级的估算比如“一台机器能不能扛住10万QPS”“这个系统需要多少台服务器”。很多人对数字没有概念张口就来结果要么把数字说大了好几个量级要么把单位搞混非常影响印象分。这里分享一个我自己常用的估算方法从CPU、内存、带宽、磁盘四个维度去估算。比如单台4核8G的标准云服务器如果处理一个请求需要100ms的CPU计算时间包括业务逻辑、序列化、IO等那么单核每秒能处理10个请求4核理论值每秒40个请求。当然这是理想值实际可能只有一半因为线程切换、GC、锁竞争都会有损耗。所以一台机器处理每秒几十到几百个请求是合理的估算范围。如果请求主要瓶颈在数据库那就要看数据库的TPS能力。单台MySQL实例的简单读写大概能到每秒几千到一万级别的TPS复杂查询可能直接掉到每秒几百。Redis的读写能力则能到每秒十万级别因为它纯内存操作。把这些数量级记牢你在做容量估算时就有据可依了。带宽的计算也容易出错。假设平均每个请求返回50KB数据每秒处理1000个请求那就是50MB/s的流量换算成带宽是400Mbps。这个数字一出来你就知道一台机器的带宽需要多大要不要走CDN或者对象存储分流。我见过候选人把MB和Mb搞混数字直接差了8倍这种细节虽然不一定会被追问但自己心里要有数。4.2 权衡思维没有完美的方案只有合适的取舍场景题里有一个高频追问“你这个方案有什么缺点”很多人听到这个问题就慌了觉得自己方案被否定了。其实面试官是想看你有没有权衡意识。任何一个方案都有适用边界你如果能把边界说清楚反而证明你是深思熟虑过的。举例来说在短链接系统里如果你选择用Redis生成自增ID优点是并发能力强、性能高缺点是Redis的持久化可能出问题万一数据丢失ID就可能重复导致短链接冲突。这时候你怎么处理一个思路是给每个节点分配独立的ID区间不同节点之间天然不会重复但会带来ID空洞的问题也就是一部分ID被跳过。这是可以接受的因为短链接本来就不需要连续。你把这个权衡讲出来面试官会觉得你很务实。再比如IM系统里如果你选择“推送拉取补偿”策略好处是消息不丢坏处是可能产生重复消息。客户端需要具备幂等处理能力也就是同一消息重复收到时自动去重。这是一个典型的“用客户端复杂度换服务端可靠性”的权衡。能把这种交换关系讲清楚的人才是真正懂分布式系统的人。我自己面试时最喜欢问的一个问题是“假如让你砍掉一个功能来换取系统稳定性你砍什么”这个问题没有正确答案但它能逼着候选人去思考系统的核心价值到底是什么。外卖系统最核心的是“订单不丢”和“骑手接得到单”而不是“界面好看”。支付系统最核心的是“账不能错”而不是“页面响应快”。你愿意砍掉次要功能来保住核心功能这就是工程判断力。4.3 时间盒思维在有限时间内输出有结构的内容面试的时间通常只有40到60分钟分给场景题的时间大概20到30分钟。这意味着你不可能把所有细节讲完必须学会“时间盒思维”在有限时间内输出最有价值的内容。我发现一个很实用的表达技巧在和面试官对齐需求后先花两三分钟把总体设计思路用三句话说清楚。比如“我打算把系统拆成接入层、逻辑层、存储层三部分接入层负责流量控制和协议转换逻辑层负责业务处理存储层负责数据落地。核心流程是A - B - C关键的非功能需求通过X方案来保证”。这三句话相当于给面试官画了一张地图他接下来就能顺着你的地图往下追问而你也掌握了对话的主导权。接下来每个模块不要平均用力要“有故事地”详略分配。核心链路、亮点设计、有冲突取舍的地方多讲几句边缘模块一句话带过。比如设计一个秒杀系统库存扣减的并发控制是亮点要展开讲而用户下单之后的通知短信就没必要展开一句“走消息队列异步发送”即可。还有一个小技巧答完之后做一个“收尾钩子”。你可以说“这个方案我目前想到的主要风险点有两点第一是XXX第二是XXX。如果要进一步完善我会优先解决第一个问题”。这样做的好处是即使你没有把每个细节都讲透面试官也会觉得你对自己的方案有清晰的边界感这种“知道自己不知道什么”的表现反而很加分。5. 备战建议如何系统性地准备场景题5.1 建立自己的“场景题库”很多人备战场景题的方式是疯狂刷面经看到一个题就背一个答案。这个方法效率极低因为场景题的变体实在太多了你不可能把所有题目都背下来。我更推荐的做法是建立自己的场景题库按“题目类型 核心考点 我的方案模板”三个维度来组织。比如“短链接系统”属于“高读低写系统设计”核心考点是发号器、缓存、301/302选择“IM系统”属于“实时通信系统设计”核心考点是长连接管理、消息路由、离线消息。你把每一类的高频考点和通用方案整理成模板面试时遇到新题先判断它属于哪一类再用模板去套就会从容很多。我当初准备时用表格把每类题目的考核点列出来比如题型典型题目核心考点我的方案关键词高读低写短链接、信息流缓存、发号器、CDN旁路缓存、预加载、降级高写低读日志系统、点击流消息队列、批量写入削峰填谷、异步落库实时通信IM、直播间弹幕长连接、路由、推送WebSocket、网关集群数据密集Top K、词频统计堆、分治、哈希小顶堆、分片归并整理完这个表你的知识就不是碎片化的而是结构化的。面试时哪怕遇到没见过的题目你也能通过“分类”的方式快速找到解题锚点。5.2 一定要动手画图、写伪代码场景题回答过程中画图是一个非常加分的动作。你不一定要画得多精美简单用信息流的方式画出请求怎么走、数据怎么落、组件之间怎么调用就能让面试官一目了然。我建议平时准备时就用白板工具或者纸笔练习练到“说到哪画到哪”的程度。伪代码也值得写。场景题不要求完整可运行的代码但关键逻辑如果能用伪代码表达出来比如发号器的实现、堆的更新逻辑、消息路由的伪代码会显得你的方案非常扎实。比如短链接的62进制转换你就可以快速写出核心循环逻辑这种基本功在面试中是瞒不了人的。有一个练习方法我很推荐把自己写的方案录成语音然后回放。你会发现自己在解释某些环节时卡顿或者逻辑跳跃。针对卡顿的地方去补充细节针对逻辑跳跃的地方去补过渡句。反复几遍之后你就能做到在面试时边想边说语气稳定节奏感很好。5.3 复盘模拟面试中的每一场卡壳如果你有条件找朋友或者同学做模拟面试是很好的方式。模拟面试的关键不在于“答得好”而在于“暴露问题”。我每次模拟完都会记录三个问题哪个问题我当时没听懂、哪个知识点我记忆模糊、哪个逻辑点我没讲明白。然后针对这三个问题去做专项复习。比如我第一次模拟IM系统设计时讲到离线消息存储面试官问“消息存储用MySQL还是消息队列”我当时就说“用消息队列”结果被追问“消息队列能保证数据不丢吗”我才意识到自己对消息队列的事务消息和确认机制理解得不够深。回家之后我花了一晚上把这个知识点补扎实后面再遇到类似问题就完全不虚了。复盘还有一个好处你能逐渐摸清面试官追问的风格。有些人喜欢追着性能指标问有些人喜欢追着一致性问有些人喜欢追着故障场景问。你练得多了就能预判对方下一步追问什么从而提前做好准备。5.4 别忘了训练“开放性问题”的临场心态场景题最考验人的其实不是知识储备而是临场心态。很多人一遇到开放性问题就慌觉得自己必须给出一个完美答案其实这反而会束缚发挥。我的建议是把场景题当成一次“技术讨论”而不是“考试”。面试官抛出题目本质上是想和你一起探讨一个问题的解法。你要敢于说出自己的假设也要敢于承认自己不确定的地方。“这块我平时接触不多但我的直觉是应该从数据一致性的角度去分析”这种表达远比硬着头皮讲一个漏洞百出的方案要好。我见过一些候选人在面试中主动和面试官说“您觉得这个方案如果上线第一批踩坑的点会在哪里”这其实是一个很高明的互动它把面试官从“评判者”变成了自己的“智囊团”同时也展示了自己的求知欲和合作精神。当然这种话术不能生搬硬套要在讨论氛围比较融洽的时候自然带出来。6. 实战复盘一道完整场景题的解答演示光说不练假把式我拿一道比较经典的题目完整演示一遍我的答题思路。题目是“请设计一个短链接系统支持点击统计要求能够支撑每天一亿条新链接的生成。”第一步我会先澄清需求“一亿条新链接生成QPS大概一千出头这个量级不算大。但点击量通常是生成量的上百倍所以点击QPS应该要到十万级别甚至更高。请问统计维度是按天还是按小时重定向要不要实时计数”假设面试官说按天统计即可但点击要实时重定向。第二步我会给出总体结构“系统分三部分生成短链的服务、重定向服务、统计服务。生成服务用发号器产出唯一ID并转成短码然后写入数据库和缓存重定向服务先查缓存再查数据库并用302重定向统计服务通过异步方式记录点击日志最终聚合到统计表。”同时画一个请求流程图用户请求短链接 - 网关 - 重定向服务 - 缓存/数据库 - 异步写入统计日志。第三步我会展开核心设计细节。发号器这里我会重点讲“可以采用分布式ID生成器给每个生成服务的实例分配一段ID区间比如每台机器一次获取十万个ID用完再向发号中心申请。这样可以避免每次都访问数据库取ID性能损耗很小。拿到ID后转成62进制短码长度大概是六个字符。”我会顺手写一段伪代码简单演示十进制转62进制的循环。第四步我会讲缓存和数据库的交互“短链接数据写入数据库时同时写入缓存缓存过期时间设置为24小时。重定向请求进来先查缓存命中率高的话数据库压力很小。万一缓存没有回源数据库查到后回填缓存。”这里我会补充一个细节为了防止缓存穿透如果一个短链接在数据库中不存在也把它缓存成一个空值但过期时间要短比如几十秒避免恶意请求打爆数据库。第五步我会讲统计模块“点击日志通过消息队列异步写入比如把重定向服务收到请求后发送一条‘短码时间来源IP’的消息到MQ后端的消费者把消息写入日志系统。由于是异步的重定向服务本身不会因为日志而变慢。每天跑一个定时任务把日志聚合成每个短链接的点击量更新到统计表。”第六步我会主动说方案的不足和改进方向“这个方案的短板在于发号器的ID是递增的短码可被预测存在遍历抓取风险。如果对安全性要求高可以在发号器生成的ID上做一次可逆混淆比如乘以一个随机数再取模但代价是复杂度上升。另外重定向服务属于无状态服务可以水平扩展加上负载均衡就能抗住很高的点击量。但数据库单点容易成为瓶颈后续可以考虑读写分离或者分库分表。”这样一套下来既覆盖了功能设计也讲清楚了对量级的应对策略还主动暴露了方案的边界和风险点。面试官如果对这个话题有兴趣自然会沿着“如何做混淆”“如何分库分表”继续追问而你因为已经提前想过这些点也能从容应对。7. 一些关于场景题的补充经验想再分享几个具体的细节这些都是在实际面试场上验证过很管用的经验。第一永远不要一上来就写代码。哪怕题目看起来是一道算法题也要先确认输入输出的边界条件和数据规模。场景题更不用说代码是最后一步前面至少有需求澄清、方案设计、复杂度分析三个步骤。你一上来就写代码等于告诉面试官“我没有系统设计思维”。第二遇到不懂的领域不要怕先尝试用“旧知识迁移”的方式破题。比如你不熟悉广告系统但你知道推荐系统里的“曝光-点击-转化”漏斗模型很多时候广告系统也能用类似的漏斗来拆解。知识迁移是高级工程师的核心技能之一面试官不会因为你没做过某个领域就否定你但会因为你毫无思路而担心你的学习能力。第三在表达方案时数字和指标比形容词更有说服力。不要只说“用缓存能提升性能”要说“用Redis做缓存读QPS可以支撑到十万级别缓存的命中率预期在95%以上”。面试官听到这样的表述会认为你对自己的方案有明确的预期也能承受后续的追问。第四结尾不要突然结束。哪怕你被追问到答不出来也可以说“这块我没有实际经验但按我的理解如果是我会这么做……您觉得这个思路有没有问题”这句话既表达了你的思考过程也给了面试官一个继续交流的入口远比沉默或者硬编一个答案好得多。第五你平时积累的技术视野也很重要。场景题虽然不考框架源码但会问“常见的限流算法有哪些”“分布式事务的几种方案”这类基础技术。这些内容本身就是场景题的“零件”零件储备不足方案再好也搭不起来。所以备战场景题时一定不能忽略对基础中间件和算法常识的学习。我个人在带团队做技术面试时最看重的是候选人能不能把一个模糊的问题结构化地拆解并且在自己知识边界内给出合理假设和取舍。这些能力不是刷题刷出来的而是靠平时写代码、看系统、复盘线上问题一点一点积累的。如果你现在正准备面试可以从今天开始用这套框架去解构自己身边的系统比如点餐App的下单流程、电商平台的订单状态流转、你公司内部系统的权限控制。等你练到能熟练拆解自己身边的系统时面试桌上再遇到任何场景题你都只会觉得是一次有趣的聊天。