“介绍一下你做的项目”——很多人用一串中间件名单回答这个问题，然后被一句”为什么要用它”问住。八股可以提前背，项目追问却会一直落到真实的业务约束、代码细节和验证证据上。本文讲三件事：STAR 法则怎么落到技术面试、如何把项目讲出深度、常见追问怎么预演。

STAR 法则在技术面试里的落地

STAR（情境、任务、行动、结果）是通用的表达框架，但技术面试里直接套用容易变成流水账，需要做一次工程化改造：

  • S（情境）要短而有信息量：一句话说清项目服务谁、解决什么问题、规模量级。不要从公司背景讲起。
  • T（任务）聚焦你个人：明确你负责的模块和要解决的问题是什么，而不是团队整体目标。”负责订单模块”信息量太低，要说清是订单创建、超时关闭还是状态机。
  • A（行动）是核心，占一半以上篇幅：你做了什么决策、写了什么代码、排除了什么方案。面试官想听的是你的思考路径，不是组件清单。
  • R（结果）必须有证据：指标提升要讲统计口径（P95 还是平均值、测试环境还是生产），故障修复要讲验证方式。没有数字时，说明观察了什么指标、结论来自什么证据，同样可信。

把项目讲出深度：挑战-方案-权衡-结果

一场好的项目深挖，本质是按”挑战 → 方案 → 权衡 → 结果”四步展开的一个工程故事。

挑战：找一个真问题

“时间紧、需求变”不是技术难点。值得讲的挑战通常落在四类：正确性（重复下单、超卖、状态错乱）、性能（慢查询、缓存命中率下降、锁竞争）、稳定性（依赖超时、消息积压、发布故障）、工程复杂度（历史代码改造、灰度迁移、兼容旧数据）。从你确实动过手的事情里挑，哪怕规模不大。

方案：讲清为什么是这一个

方案部分要交代候选路线和选择依据。比如订单超时关闭，可以扫表定时任务、Redis 过期通知、延迟消息，各自的限制是什么；你的项目量级、基础设施和团队经验为什么指向当前这个。离开约束谈选型没有标准答案，承认这一点反而加分。

权衡：主动说出代价

这是区分”做过”和”背过”的关键。引入缓存就有一致性问题，引入消息队列就有重复消费和积压风险，异步化就有排查链路变长。主动讲”这个方案牺牲了什么、我们怎么兜底”，比等面试官追问被动得多。

结果：给可核对的证据

优化前后对比要说明测量条件：数据量、并发模型、机器配置、统计口径。没有生产数据就如实说测试环境，编造的 QPS 在追问下撑不过三轮。

常见追问预演清单

把简历放在面前，沿技术栈逐项自审。以下几组几乎必问：

为什么这样设计？

架构上每出现一个组件，先自问三个问题：它在链路里承担什么、去掉会怎样、它不可用时系统怎么降级。只回答”Redis 快所以用 Redis”，很快就会进入盲区。

遇到什么问题？

准备一个完整的排障过程：怎么发现（告警还是用户反馈）、怎么确认影响面、怎么止血（回滚、限流、降级）、怎么定位根因、修复后怎么验证、补了什么防复发机制。临时措施的副作用也要说，比如重启能止血但会丢现场。

指标如何？

流量、延迟、错误率、数据量都要能讲口径：峰值还是常态、P99 还是均值、统计窗口多长。简历上每个数字背后都要有一份材料支撑，哪怕是脱敏后的结论记录。

哪些是你做的？

诚实划分职责边界。表是你设计的、部署由平台团队负责，就照实说。面试官能接受范围有限，但不能接受虚构——把”调研过”说成”已上线”是最常见的翻车点。

最后留一个自查动作：合上资料，用 30 秒和 3 分钟各讲一遍项目，画得出核心链路和一条异常链路，说得清三个亲手实现的功能位置。都能做到，项目这一关基本就稳了。