STAR法则：面试讲故事的正确方式

STAR = Situation（情境）+ Task（任务）+ Action（行动）+ Result（结果）

┌────────────────────────────────────────────────────┐
│ S │ 情境 │ 项目背景、技术栈、团队规模、当时面临的局面    │
│ T │ 任务 │ 你负责什么？你的个人目标是什么？             │
│ A │ 行动 │ 你具体做了什么？技术选型、方案设计、攻坚难点  │
│ R │ 结果 │ 最终效果是什么？量化指标！                   │
└────────────────────────────────────────────────────┘

好的 S：
  ❌ 我们做了一个订单系统
  ✅ 我们团队 5 个人接手了一个日均订单 10 万的订单服务，之前的架构是单体，
     部署一次要 30 分钟，上线频率很低，需求堆积严重。

关键要素：
  - 项目背景（业务场景）
  - 技术栈（让面试官快速定位你的技术方向）
  - 团队规模（个人贡献和团队协作的铺垫）
  - 当时的问题（为什么需要改变）

好的 T：
  ❌ 我负责后端开发
  ✅ 我作为后端负责人，负责将订单服务从单体拆分为微服务，
     目标是降低部署时间和提升系统稳定性。

关键要素：
  - 我的职责（不是泛泛的"后端开发"）
  - 目标（可量化的目标最好）
  - 约束（时间、团队、遗留代码等）

好的 A：
  ✅ 1. 调研了 Spring Cloud 和 Dubbo，最终选型 Spring Cloud（Nacos 注册中心+Feign 调用）
     2. 设计了服务拆分方案，按领域划分订单、商品、支付三个服务
     3. 解决了数据迁移的难题：订单表 5000 万数据，做了双写双读方案保证平滑切换
     4. 引入链路追踪（SkyWalking），解决跨服务调用排查困难的问题

关键要素：
  - 具体技术选型理由
  - 你独有的贡献（不是"我们团队"）
  - 攻坚难点（最有价值的部分）
  - 体现能力的行动（架构设计/性能优化/团队协调）

好的 R：
  ✅ 1. 部署时间从 30 分钟降到 3 分钟，上线频率提升 10 倍
     2. 系统可用性从 99.5% 提升到 99.99%，全年故障时间减少 90%
     3. 订单量从日均 10 万增长到 50 万，系统平稳支撑

关键要素：
  - 必须量化（数字说话）
  - 对比提升（前 vs 后）
  - 个人成长（学到了什么）

S（情境）：
  我们负责的接口服务日均 QPS 50 万，P99 延迟 800ms，经常收到用户投诉。
  排查发现慢查询占比 40%，数据库 CPU 使用率 95%。

T（任务）：
  我负责性能优化，目标是 P99 降到 200ms 以内。

A（行动）：
  1. 用 Arthas 定位慢查询根因：发现订单列表接口有一次 N+1 查询
     （每次查订单后循环查用户信息）
  2. 优化为 JOIN 查询 + 添加联合索引，查询时间从 300ms 降到 30ms
  3. 引入 Redis 缓存热点订单数据，命中率 85%，减少 70% 的数据库请求
  4. 升级连接池（Druid → HikariCP），数据库连接获取时间降低 40%
  5. 全链路压测验证优化效果

R（结果）：
  P99 延迟从 800ms 降到 150ms，QPS 提升 3 倍支撑日均 150 万请求，
  数据库 CPU 从 95% 降到 40%，节省了 2 台数据库服务器。
  这个经历让我深入理解了 MySQL 执行计划和索引原理。

S（情境）：
  公司的秒杀系统每次大促都要提前扩容，扩容成本高，而且扩容后资源利用率只有 30%。
  秒杀峰值 QPS 10 万，系统经常在高峰期扛不住。

T（任务）：
  我主导设计了一套弹性伸缩 + 多级缓存的秒杀系统，目标是在零扩容的情况下支撑峰值流量。

A（行动）：
  1. 引入 Redis 分布式锁 + Lua 脚本实现库存原子扣减，从根本上防止超卖
  2. 设计三级缓存：本地缓存（Caffeine）→ Redis → 数据库
  3. 用 MQ 异步处理下单流程，实现流量削峰，避免直接打垮数据库
  4. 对接 Kubernetes HPA，实现基于 CPU 和 QPS 的自动扩缩容

R（结果）：
  大促期间零扩容，节省服务器成本 60%，P99 延迟控制在 100ms 以内，
  系统平稳度过峰值（QPS 峰值 12 万），并通过了零点流量的验证。
  这套方案后来推广到了其他高并发场景。

PARLA = Problem（问题）+ Approach（方法）+ Result（结果）+ Learning（学习）+ Application（应用）

PARLA 比 STAR 更强调个人成长和应用

什么时候用 STAR？
  - 面试中回答项目经历、难点挑战
  - 描述具体的项目成果

什么时候用 PARLA？
  - 描述一次技术学习或踩坑经历
  - 强调自己的成长和可迁移能力

❌ 我的项目就是增删改查，没什么亮点

✅ 找出普通项目的亮点：
  - 性能优化：CRUD 也能慢，SQL 优化、索引优化
  - 稳定性保障：怎么做容灾？有没有做监控告警？
  - 技术选型：为什么选这个技术栈？
  - 团队协作：怎么协调前端后端测试？
  - 需求挑战：需求不合理怎么沟通的？

❌ 我们团队做了...

✅ 突出个人贡献：
  - "我负责的模块是..."
  - "我主导设计了..."
  - "针对 X 问题，我提出了 Y 方案..."
  - 如果你确实只是执行者，强调你在执行过程中的思考

方法：横向扩展（时间维度、数量维度）

"没有大项目"：
  → 把小项目讲深（技术选型理由、遇到的问题、解决方案）
  → 多做几次小优化积累（性能优化 3 次、架构改进 2 次）

方法：量化一切

  ❌ 优化了接口响应速度
  ✅ 接口 P99 延迟从 1200ms 降到 180ms，提升 6.7 倍