这不是说教，是我们组最近刚踩过的坑。
事故经过（简版）
新来了个后端实习生，小伙子聪明、手快，分给他一个看起来独立的业务：对账服务里加一个“快速补单”的后台接口。需求很直白：给定订单号，尝试补发结算，支持并发调用，尽量快。
他直接用 AI 生成了控制器、Service、DAO，跑通了自测用例，还贴心地加了“失败重试”。结果上线当天，生产报警：结算金额对不上、重复扣款、下游库存回滚异常。排查了半天，最后定位到他这条补单链路。
问题根因不复杂，但很典型：
- 接口是“幂等”的假象：用订单号当幂等键，但内部实际产生了两条不同的结算任务，因为异步队列的去重键不是同一组字段。
- 重试是“放大器”：把下游偶发超时当作可重试错误，且无指数退避与重试上限，导致短时间风暴。
- 一致性没有“护栏”：本地状态先落库、远端状态后确认，中途失败没有事务性补偿与回滚窗口，导致“半成功”挂住。
- 延迟预算被“吃光”：为了“快”，把三类校验搬到异步——看起来更快，实则把失败变“延后爆炸”，灰度期没暴露，放量后一起炸。
说白了：代码能跑，逻辑不稳；单点对了，联动错了。
为什么要考基础？因为你要“看得懂 AI 生成的代码”，还能“看穿它没写出来的部分”
AI 很能写，但它默认你已经想好了“边界与取舍”。没有这些边界，生成出来只是“看似正确的路径”，不等于“在你的系统里安全的路径”。考基础，不是为了背术语，而是为了确保工程师具备下面三种能力：
- 问清目标函数与约束
- 延迟目标是 p95 还是 p99？可用性底线是多少？成本/配额约束如何？失败如何定义与分级？
- 这些没定，代码对错没有评价坐标。
- 识别关键工程骨架
- 幂等键放哪一层？一致性模型是最终一致还是强一致？是否需要“先写本地再发异步”的补偿设计？
- 队列的去重键与上游幂等键一致吗？是否要限流/背压？重试策略是否区分“可重试/不可重试/幂等安全”？
- 建立“验证闭环”
- 上线前有没有 p99 延迟、错误分类、幂等冲突率、回滚窗口的可观测项？
- 是否灰度、是否有熔断与降级路径、事故演练过哪些失败场景（超时风暴、重复提交、不一致、脏数据、第三方抖动）？
实习生这次的问题，不是“写不出来”，而是“看不出来哪里该停下问一句”：
“这里的幂等键和队列去重键对齐了吗？”
“这个重试是否会把幂等缺陷放大？”
“一致性失败怎么补偿？回滚窗口多长？”
“p99 的延迟预算里，哪些校验不能异步化？”
这些问题，本质上就是基础。
三条教训：写之前先把‘护栏’立起来
- 幂等先于重试
- 先确定“同一业务语义”的幂等键与作用域，再谈重试。所有产生副作用的路径，先定义幂等策略（键、存储、过期、可见性），再加重试。否则重试就是事故的放大器。
- 一致性先于快
- “先落库、后异步”要么配事务外补偿机制（补偿任务持久化、可重放、可观测），要么明确回滚窗口与人工兜底路径。把关键校验异步化只是在推迟问题爆发，不是降低风险。
- p99 先于平均值
- 把延迟预算写出来并分配到每一跳：校验、调用、重试、排队、回写，各占多少。平均值很会骗人，p99 才是你上线后的日常。
面试怎么落地？三件可操作的小事
- 让候选人复盘一次“取舍”决策：为了什么目标，放弃了什么方案，依据是什么数据或约束。
- 让候选人给一个“上线前验证清单”：p99 延迟、错误分类、幂等冲突率、一致性补偿、回滚窗口、监控指标与阈值。
- 让候选人口头演练一次“失败场景”：当超时风暴/重复提交/不一致/第三方抖动来临，他会怎么用队列、缓存、索引、幂等、限流、重试、分层、灰度、回滚去止血。
这三件事，不需要背术语，却能显著区分“只会用 AI 生成代码的人”和“能读懂、能把关、能对系统负责的人”。
AI 能帮你把“怎么写”做得很快；但“为什么这样做”“做到什么程度才算对”，仍然得靠基础。基础不是八股，它是你在复杂系统里建立护栏、发现隐患、把结果对齐业务目标的能力。我们不是反对 AI，而是希望把它放在一个安全的轨道里跑。
