工作这些年，我见过太多程序员写代码——写完就丢，出了bug就加班修，周而复始。几年下来，技术栈换了三四套，项目做了十几个，但真正沉淀下来的东西却少得可怜。
而另一类程序员，他们的成长速度往往快得让人惊讶。深入了解后你会发现，他们有一个共同习惯：写技术复盘。
听起来是老生常谈，但今天我想认真聊聊，为什么这件事的回报率远超你的想象，以及怎么写才真正有效。
一、复盘的本质：把经验变成可迁移的能力
我们从小被教育要「从错误中学习」，但很少有人教我们怎么「学习」这件事本身。
一个典型的场景：你在项目里遇到了一个 Redis 缓存穿透问题，查了很久，最后在 Stack Overflow 上找到了解决方案。复制粘贴，问题解决了，然后继续下一件事。
三个月后，同样的问题再次出现——你忘了。
这不是记忆力差，而是因为孤立的经验不会被大脑优先提取。只有当你主动整理、归类、抽象这些经验时，它们才会变成你知识体系的一部分。复盘的本质，就是做这件事。
二、技术复盘写什么？
真正有价值的复盘，应该包含以下四个维度：
1. 问题描述（Context）
在什么场景下发生的？触发的具体操作是什么？影响范围多大？不要只写「MySQL 查询慢」，要写「用户量超过5000时，订单列表页平均响应时间从80ms上升到3.2s」。具体的数据是后来快速定位问题的关键。
2. 根因分析（Root Cause）
这是最容易被跳过的部分，但也是最有价值的部分。使用「五个为什么」方法，不断追问直到找到真正的根因：
问：为什么接口超时？
答：因为数据库查询慢。
问：为什么数据库查询慢？
答：因为缺少索引。
问：为什么缺少索引？
答：因为这个字段是后期新增的，上线时没有评估索引覆盖。
问：为什么没有评估？
答：因为没有建立字段新增时的索引审查流程。到了第四层，你才发现真正的问题不是「加索引」，而是「流程缺失」。这个洞见，才是可以复用到其他场景的知识。
3. 解决方案（Solution）
你做了什么修复？是否验证有效？有没有副作用？这里要区分「临时方案」和「根本解决方案」，并在注释中标注清楚。
4. 可复用的规律（Pattern）
这是复盘的点睛之笔：从这个问题里，你能抽象出什么原则？
- 所有新增字段必须经过索引评估
- 涉及金额计算的代码必须有防浮点精度陷阱的注释
- 任何对外接口都要有超时和降级处理
这些规律，就是你从具体经验中提炼出来的「元知识」，比任何一本书都更适合你。
三、工具不重要，持续才重要
很多人纠结用什么工具写复盘：Notion、Obsidian、飞书文档、GitHub Issues……其实用什么都可以，只要满足两个条件：
- 随时能记（手机、电脑都能访问）
- 方便检索（过了三个月还能找到）
我的个人习惯是：遇到问题当场在备忘录里记三句话——问题、原因、结论。等有空了再扩展成完整复盘。
四、复盘给我带来了什么？
坚持写技术复盘两年后，我发现了几个明显的变化：
- 同类问题不再踩第二次：积累了几十篇复盘后，很多坑我能在写代码时就预见到
- 讲技术方案时更有底气：因为背后有案例和数据支撑，而不是「我觉得」
- 带团队时更容易说服别人：当你拿出具体的事例说明为什么需要加这个流程，阻力小很多
能力的积累从来不是线性的——不是每解决一个问题就会自动变强。只有当你主动整理、反思、抽象这些经验时，它们才会真正属于你。
从今天开始，给自己建一个「错题本」吧。不是为了记录失败，而是为了让每一次踩坑都成为未来的垫脚石。
