技术简历上写「使用 Kafka 实现异步解耦」和写「在 Kafka 和 RabbitMQ 之间选了前者因为……」是两个层级。前者说明你会用后者说明你会判断。而工作年限越长后者的权重越高。为什么选型经历值钱因为它暴露的是你的思考过程而思考过程没法背。一个只跟着团队用过某个组件的人说不出当时为什么选它一个参与过选型的人会记得当时的约束条件、备选方案、和被放弃的理由。技术面试官非常喜欢问这类问题因为它一问就能分层。四个要素一个完整的选型经历包含约束条件。当时的场景、规模、团队情况、时间预算。没有约束就没有选型只有偏好。备选方案。你考虑过哪几个各自的特点。判断依据。为什么最终选了这个依据是什么。最好有实测数据而不只是文档上的描述。代价与边界。这个选择的缺点是什么什么情况下你会选别的。第四个最容易被忽略也最能体现水平。任何技术选择都有代价说不出代价的人通常是没真正做过选择。改前改后改前- 使用 Elasticsearch 实现商品搜索功能支持多条件筛选和分词检索这句话只说明你用过。改后- 商品搜索的选型与落地。约束商品约 300 万、日均搜索 40 万次、需要支持中文分词与 8 个维度的组合筛选团队 3 人且没人有搜索引擎经验排期 6 周 - 备选MySQL 全文索引 / Elasticsearch / 直接用云厂商的搜索服务。用真实数据做了一轮对比MySQL 全文索引在中文分词上效果差用的是 ngram召回噪音大组合筛选时 P99 到了 2sES 分词效果好但要自己运维云服务开箱即用但单月成本是自建的 3 倍多 - 选了 ES 自建主因是成本和可控性且我们的查询模式简单不涉及复杂聚合运维压力可接受。为了对冲团队没经验的风险只用了最基础的功能IK 分词 bool 查询 filter 缓存不碰自定义评分 - 代价多了一套需要运维的组件且数据同步MySQL 到 ES引入了秒级延迟我们在商品上架流程里做了「写完主动刷一次」来规避用户可感知的延迟。如果当时团队只有 1 个人或者查询需求更复杂我会选云服务改后这一段面试官可以从任何一句往下问而且每一句你都答得出来因为都是真事。最后那句「如果当时团队只有 1 个人我会选云服务」尤其加分它显示你知道这个决策是场景依赖的不是信仰。如果你不是决策者很多人的情况是选型是架构师或者 leader 定的自己只是执行。这种情况可以写但要如实- 该方案由架构组确定我负责落地。落地过程中发现文档里没提到的一个问题IK 分词器的热更新词典在容器化部署下需要挂载共享存储否则多副本的词典会不一致。补了这部分方案并写进了组内的部署文档诚实地说明你的角色然后写你在执行中真正贡献的部分。这比冒领决策权好得多而且后半段同样有技术含量。另一种写法是写「你理解的决策依据」- 方案由架构组确定。我梳理过当时的判断依据成本、团队经验、查询复杂度三项并在后续的分表方案讨论中沿用了同一套评估框架这显示你不只是执行而是在学习判断方式。选错了怎么写这是很多人的顾虑当时选了 A后来证明 B 更合适要不要写要写而且是加分项前提是你能说清楚复盘。- 消息队列最初选了 A 方案主要考虑是团队熟悉、部署简单。上线 4 个月后随着消息量增长到日均 2000 万遇到了积压时消费端重平衡耗时过长的问题单次 30 秒以上期间消费停滞 - 复盘下来当初的评估漏了一个维度只评估了当时的量级没有评估 12 个月后的量级和对应的运维复杂度。后来迁到了 B 方案迁移用双写 分批切流做了 3 周 - 这次之后我在选型评估里固定加了一条按 12 个月后的预估量级再算一遍而不是只看当下最后那句是这段的价值所在。它说明这次失误转化成了一个可复用的方法。技术面试官见过太多顺风顺水的简历一个能讲清楚自己判断失误和修正过程的候选人可信度反而更高。哪些「选型」不值得写选了一个框架的某个版本、选了一个 UI 组件库、选了用哪种日期处理库这类没有实质权衡的选择不用写。判断标准是这个选择有没有明确的代价如果换一个方案系统会有实质不同吗没有的话它就是偏好不是选型。面试里的延伸准备好这三个追问「如果当时规模大 10 倍你还会这么选吗」考的是你对方案边界的理解。「你怎么验证这个选择是对的」考的是你有没有做实测还是只看文档。「现在让你重做一次会有什么不同」考的是复盘能力。三个问题都答得上这段经历就守得住。最后技术简历从「会用」升级到「会判断」最有效的途径就是把选型经历写出来。一段选型经历能撑起五到十分钟的面试对话而一句「使用了某某技术」只能撑十秒。