项目准备
项目准备需要把实际做过的工作整理成可解释、可追问、可验证的材料。课程项目、个人作品和实习经历都可以使用下面的结构，深入程度由目标岗位与真实经历决定。
1. 一页项目材料
先画出主要请求经过哪些组件、数据保存在哪里，再填写下表。每项只保留能够影响实现或解释的事实。
| 项目材料 | 要回答的问题 | 可用证据 |
|---|---|---|
| 背景与约束 | 谁使用，解决什么问题，哪些要求必须满足？ | 需求说明、输入输出、规模假设 |
| 个人贡献 | 本人负责哪些接口、表、模块和验证？ | 提交记录、接口定义、测试 |
| 关键链路 | 一次请求怎样读写数据，哪里可能失败？ | 时序图、表结构、日志 |
| 技术选择 | 为什么用这个方案，有什么代价？ | 与一个可行替代方案的比较 |
| 正确性 | 重复、并发、超时、异常时会发生什么？ | 边界用例、约束、故障复现 |
| 结果与局限 | 实际验证了什么，哪些仍是假设？ | 运行环境、测量方式、未完成项 |
无需给简单项目补上全部中间件。能够解释不用缓存或 MQ 的原因，也是一项设计判断。
2. 教学示例：课程预约
假设项目允许学生预约课程，要求名额不能小于零，同一学生不能重复预约同一课程。以下是准备材料的示范，读者应换成自己实际实现的内容。
关键链路：接收请求 → 校验身份和参数 → 在事务内处理名额与预约记录 → 提交 → 返回结果。先明确数据库中的约束，再讨论是否需要缓存。相关原理见数据约束、数据库事务和InnoDB 锁。
核心追问：
- 两个请求同时抢最后一个名额，哪一步保证不会超出容量？请按自己采用的 SQL 和锁策略画时序。
- 预约记录写入失败时，名额修改是否回滚？异常在哪一层处理，事务是否实际生效？
- 用户提交后没有收到响应，再次请求时，如何区分“上次失败”和“已经成功”？
- 如果加入缓存，数据库和缓存分别负责什么？缓存失效或更新失败时会有什么后果？
这里没有一套适用于所有项目的固定答案。能够写出正常路径还不够，需要指出保证依赖的约束、事务边界和重试规则；参考Spring 事务、幂等键与缓存一致性。
自行验证的最小集合：普通预约成功；名额为零；相同请求重复提交；最后一个名额发生竞争；事务中途失败；取消请求重复执行。预先写出每个场景的预期结果，检查数据库和返回值，不以页面显示成功代替数据校验。
3. 技术追问的回答顺序
先说明当时的约束和现象，给出采取的方案，再沿执行链解释为什么成立，最后说明代价与未验证范围。
例如被问“为什么使用线程池”，应从实际任务的执行方式、并发限制、队列和失败处理展开。如果项目没有异步任务，直接说明没有使用，再讨论在新增需求下如何设计。原理见Java 线程池。
项目卡片可以复制到自己的笔记中：
问题或故障：
当时的约束：
本人定位到的证据：
选择的方案及替代方案：
关键执行过程：
验证方式与结果：
代价和未解决问题：
关联知识文章：
4. AI 辅助开发经历
如果使用过 AI 编程工具，准备一个你实际审查或纠正输出的例子：任务如何描述、工具给了什么、你如何检查、发现了什么问题、最终怎样验证。基础代码检查可以参考算法正确性与JUnit。
工具给出的代码、解释和测试仍需核验。对涉及数据、并发或权限的修改，至少检查约束、错误路径和公开接口；无法解释的生成内容不能作为已经掌握的能力。
部分 2027 校招岗位还明确要求大模型 API、RAG 或 Agent 应用。只有目标岗位或自己的项目涉及这些内容时，再准备检索质量、结果验证、超时与成本等专项问题。普通后端项目无需为了简历名称临时加上 AI 功能。
5. 面试前独立演练
用两分钟讲清背景、本人负责的链路和一个关键问题；随后不看材料回答三道追问。卡住时，在自己的记录中写下缺少的是事实、机制还是证据，再回到代码或相应文章查证。最后检查讲述是否与简历一致。