银行科技岗技术面：用 STAR 法讲清项目与实习经历

《面试题目》

项目与实习经历的问法

1. 请讲一下你简历上的这个项目具体做了什么？
2. 这个功能为什么这么设计？
3. 用了什么技术，踩过什么坑，怎么填的？
4. 换一种方案行不行？
5. 你项目里有什么难点，是怎么解决的？
6. 这个技术（方案）是用来解决什么问题的？原理和关键细节是什么？
7. 当时还有哪些别的路子可以走，也就是有哪些备选方案？
8. 为什么最后选了这一条，没选其他的？
9. 别的路子有什么问题或不足，在你的场景下为什么不合适？

以「交易履约与库存中心」为例的技术追问

10. 为什么库存放在 Redis 里用 Lua 扣减，而不是直接操作数据库？
11. 为什么用本地消息表，而不是直接发 MQ 或者依赖 MQ 的事务消息？
12. 状态机更新为什么要带 version 或者原状态条件？
13. Redis 已经做了库存预占，为什么数据库还要保存预占记录？
14. 为什么选 RocketMQ 而不是其他消息队列？

《参考解析》

1. 项目整体怎么讲：按 STAR 四段走——情境（业务背景与场景）、任务（你的角色与要达成的目标）、行动（用了什么技术、怎么设计、怎么落地）、结果（量化数据）。行动段是重点，讲得越具体越好；结果段能给性能、并发量、耗时、正确率这类数字，就别只说效果不错。
2. 难点怎么挑：每个项目挑 2–3 个自己真的动手解决过的问题，高并发下的数据一致性、异步消息丢失、接口性能瓶颈、热点请求都算。每个难点同样按问题、方案、取舍、结果讲一遍，把一个难点讲透比泛泛铺十个功能点有说服力。
3. 选型追问怎么答：固定四步——这个方案解决什么问题、原理和关键细节是什么、当时有哪些备选、为什么落到它。面试官不要求你的方案是业界最优，看的是你有没有思考过取舍；实在答不上来，把团队已有技术栈和运维成本这类真实约束讲清楚，比硬编一个理由安全。
4. 库存为什么用 Redis 加 Lua：高并发下直接用数据库行锁扣库存，请求会堵在同一行上，数据库压力大、响应慢。Redis 在内存里、QPS 高，Lua 脚本把判断库存、判断限购、扣减合成一次原子执行，由单线程跑完不被打断，既快又不容易超卖；数据库只做持久化与对账兜底，Redis 数据异常时还能依据预占记录纠偏。
5. 本地消息表与直接发 MQ 的区别：先提交业务事务再发消息，中间有一个宕机窗口——业务成功了消息没出去，下游永远不会执行。本地消息表把业务数据和消息记录放进同一个本地事务，要么都成功要么都失败，再由任务异步投递、失败重试，不依赖特定 MQ 的事务消息能力，实现通用可控；代价是消息有延迟，重试和死信要自己管。
6. 状态机为什么带 version：订单状态可能同时被用户请求、MQ 消费、定时任务三个来源推进，不带条件的更新会把状态覆盖错，比如已经退款又被改成已完成。所有更新带上 version 或「当前必须是某个原状态」的条件，就是用乐观锁把状态限制在预设的合法流转路径上，冲突时更新失败重试而不是覆盖。