很多候选人准备技术面试时投入了大量时间背题：集合、线程、数据库、缓存、网络、框架、算法。结果一到项目面，还是被问得很被动。不是背题没有价值，而是背题解决的是“我知不知道概念”，项目面考的是“我能不能把概念用在真实问题里”。
面试官不是随机挑知识点刁难你。他通常会沿着你的项目找证据：这个问题为什么存在，你为什么这样设计，失败时怎么处理，效果怎么验证，下一次怎么改。只背概念，很难回答这些问题。
背题容易让回答变短
标准答案往往很短。比如问缓存击穿，背题答案可能是“加互斥锁或逻辑过期”。但项目面里，面试官会继续问锁粒度、拿不到锁怎么办、能不能读旧值、数据库压力怎么验证。你如果只准备了概念，就会突然没话说。
准备时要把每个知识点扩展成一个小场景：它解决什么问题，适用于什么条件，有什么副作用，项目里怎么验证。能回答这四个问题，知识点才开始变成面试能力。
项目不是功能列表
很多简历项目写得很满，但面试时只能讲功能。功能本身通常不难，难的是约束和取舍。登录、下单、列表、上传、推荐、搜索、报表，这些功能都可以讲出工程问题：重复提交、权限边界、慢查询、文件大小、结果排序、指标口径。
如果你发现自己的项目只能介绍“实现了什么”，说明还没有准备到位。至少要选一个模块，讲清业务背景、个人职责、技术难点、失败场景、验证方式和复盘点。
不会的问题不要硬编
真实面试里遇到不会的问题很正常。危险的是硬编。面试官通常能听出答案是否自洽。更好的做法是先划边界：这个细节我没有在线上实际处理过，但我会从哪些方向定位。然后给出推理路径。
比如被问到数据库锁问题，如果你不确定具体锁类型，可以说：我不能直接断言锁的类型，但我会先看事务范围、执行计划、更新条件是否命中索引，再通过数据库状态和慢查询确认是否存在锁等待。这样的回答至少展示了解决问题的方法。
复盘比完美更可信
很多候选人害怕讲项目缺点，担心被扣分。其实真实项目很少完美。能说出当时没做好的地方、后来怎么补、下一次怎么提前设计，反而更可信。
复盘可以很具体：最开始没有埋点，导致上线后只能从日志里补查；接口缺少幂等，联调时出现重复请求；数据库索引只按功能设计，数据量上来后才发现慢查询；异常提示太粗，排查成本高。这些经历如果讲清楚，会让面试官相信你真的做过。
更有效的准备方式
可以用一张表整理项目。每行不是一个功能，而是一个追问点：为什么做、替代方案、风险、异常、指标、复盘。再把常见知识点挂到这些追问点上。比如 Redis 不只是缓存定义，而是商品详情页的读压力；事务不只是注解，而是订单状态流转；索引不只是最左前缀，而是列表查询慢的排查过程。
背题仍然需要，但它应该服务项目表达。先有真实场景，再补知识点，面试时会自然很多。
技术面试真正考的不是谁背得最多，而是谁能把有限经历讲得具体、诚实、可验证。准备方向一旦从“背答案”转成“讲清问题”，面试表现会稳定得多。
把背题转成项目追问
背题有用，但不能停在答案。更有效的方法是把每个知识点转成项目追问：它解决什么问题，在哪个场景用过，不用会怎样，出了问题怎么排查。
线程池：背题式准备是背参数，项目式准备是讲任务堆积和隔离，自测问题是队列满了怎么办。Redis：背题式准备是背穿透击穿雪崩，项目式准备是讲缓存一致性取舍，自测问题是哪些字段允许旧值。
- MySQL：背题式准备是背索引规则，项目式准备是讲一次慢查询排查，自测问题是如何证明优化没改错。
- 网络：背题式准备是背握手挥手，项目式准备是讲超时和重试，自测问题是重试会不会放大故障。
文章可以提醒读者：面试准备不是把答案变长，而是把答案变得可追问。每个概念都能接住两层追问，项目面才会稳。