它到底是什么？

简单说，ADR 就是 给重要的技术决定写“日记”。

当我们在项目里做出一个重要的、会影响很久的技术选择（比如“我们用哪个数据库？”、“服务之间怎么通信？”）时，就创建一个简短的文档，写下：

1. 我们遇到了什么问题？

2. 我们决定怎么做？

3. 最重要的是——为什么这么选？

这份文档和代码一起保存，作为永久的记录。

解决了我的什么痛点？

• 对抗遗忘：半年后，自己或新同事问“我们当初为啥用这个？”，翻看ADR就有答案。记忆会模糊，但文档不会。

• 停止扯皮：同一个问题讨论过、拍板了，下次有人再想争论，把ADR给他看。避免在相同问题上反复消耗精力。

• 新人指南：新同学想快速了解系统设计的前因后果，读一遍ADR列表比读万字设计文档有效得多。

• 让决策更靠谱：写“为什么”的过程，强迫自己理性思考、权衡利弊，而不是拍脑袋。

和传统设计文档有什么不同？

ADR模板

# [标题：清晰说明决定内容]

**状态**：[提议 | 已接受 | 已弃用 | 已替代]
**日期**：YYYY-MM-DD
**决策者**：[相关人员]

## 背景
（当前遇到了什么情况？有什么问题或需求促使我们必须做出这个决定？）

## 决定
（我们最终决定怎么做？用肯定句陈述。）

## 理由
（这是核心部分。我们考虑了哪些方案？各自的优缺点是什么？基于什么标准（成本、性能、团队熟悉度等）做出了现在的选择？）

## 后果
（这个决定会带来什么影响？好的一面和坏的一面都要写。）
*   **积极影响**：比如性能提升、维护变简单。
*   **消极影响/风险**：比如学习成本增加、系统变复杂。
*   **需要做的事**：哪些代码要改？需要什么新任务？团队需要学习吗？