很多同学准备项目面，会把主要精力放在“我做了什么功能”上：用户登录、订单查询、权限管理、缓存优化、消息通知。问题是，面试官真正想听的往往不是功能列表，而是你在项目里如何发现问题、做选择、承担结果。
项目深挖之所以难，是因为它不靠背诵。面试官可能从你简历里任意一句话切入：你说提升了性能，怎么衡量？你说用了 Redis，为什么不是本地缓存？你说做了异步，失败怎么补偿？如果这些问题没有提前想清楚，项目再多也容易被问散。
第一层：业务场景是否讲得清
一个项目开场不要急着讲技术栈。先讲业务场景：这个系统给谁用，解决什么问题，你负责哪一段。比如“我做了一个后台管理系统”太泛，“我负责订单审核后台里的批量审批和异常状态处理”就清楚很多。
业务场景清楚以后，技术才有意义。缓存、异步、索引、限流都不是为了显得高级，而是为了解决某个具体压力点。面试官听到清楚的业务背景，后面的追问会更容易围绕你的真实工作展开。
第二层：个人职责要具体
项目是团队做的，面试官更关心你个人做了什么。不要把团队成果全部说成自己的，也不要只说“参与开发”。更好的表达是：我负责哪个模块，参与了哪些设计讨论，写了哪些核心接口，解决过哪些问题。
如果你只负责一个小模块，也可以讲得有价值。比如你负责的是导入任务，就可以讲文件解析、批量校验、错误行回显、异步执行、任务状态流转。小模块只要讲清楚边界和异常，也能体现后端能力。
第三层：技术选择背后的取舍
面试官最常追问的是“为什么”。为什么加缓存？为什么用 MQ？为什么不用同步调用？为什么索引这样建？这些问题不是为了刁难，而是看你是否理解方案代价。
缓存能提升读取速度，但会引入一致性问题；MQ 能削峰解耦，但会带来重复消费和补偿；联合索引能优化查询，但会增加写入维护成本。能把收益和代价一起讲出来，项目就不像照着教程做的。
第四层：线上结果和证据
项目不是讲完方案就结束，还要讲结果。结果可以是接口耗时下降、慢查询减少、失败率降低、人工处理时间缩短，也可以是上线后发现了某个问题并修复。关键是要有证据意识。
如果没有精确数字，也可以讲观察方式：看过哪些日志，关注哪些监控，如何确认改动生效。比如“上线后观察接口耗时、数据库慢查询和错误率，没有出现明显回退”，就比“效果还不错”更可信。
第五层：异常路径和复盘
真正有经验的项目表达，一定会讲异常路径。用户重复提交怎么办？下游接口失败怎么办？消息消费失败怎么办？缓存失效瞬间怎么办？权限校验漏了怎么办？
面试官喜欢追问异常，是因为真实系统大部分复杂度都在失败路径里。你可以准备一两个项目里的典型问题：一次慢查询、一次消息堆积、一次缓存不一致、一次发布回滚。能讲清复盘，比只讲成功路径更有说服力。
第六层：如果重做会改什么
最后一层是改进意识。项目不是越完美越好，真实项目都有历史包袱和取舍。你可以说如果重做，会补充监控、收敛状态机、拆分慢接口、减少重复代码、完善压测或灰度流程。
这种表达不会扣分，反而说明你知道项目的边界。面试官真正想听的，是你从项目中学到了什么，而不是你把项目包装得毫无缺陷。
准备项目面时，可以把每个项目压成一页：业务场景、个人职责、关键取舍、上线证据、异常路径和复盘改进。面试时不需要机械背这一页，但任何追问都能从这里展开。