采用React函数组件与Hooks：已采纳，2023年决定。背景为类组件维护难、逻辑复用差；决策选用函数组件与Hooks；理由包括更优的逻辑封装、社区趋势、团队熟悉；影响涉及更新开发规范、培训成本；替代方案含类组件继承（复杂度高）和HOC（嵌套深）。
设计前端项目的架构决策记录（Architecture Decision Record, 简称ADR）是为了清晰地追踪项目中关键技术选择的背景、依据和影响。它帮助团队在长期维护中理解“为什么当初这么设计”，避免重复讨论或随意变更。
明确ADR的核心内容结构
每条ADR应包含固定字段，确保信息完整且易于查阅。建议包括以下部分：
- 标题：简洁描述决策主题，例如“采用React函数组件与Hooks”
- 状态：如提议中、已采纳、已废弃、已替换
- 日期：决策提出或确认的时间
- 背景：说明问题场景，比如性能瓶颈、协作困难、技术债务等
- 决策：明确最终选择的方案
- 理由：列出支持该决策的关键因素，如社区支持、团队熟悉度、可维护性
- 影响：对开发流程、构建工具、部署、测试等方面的影响
- 替代方案：简要说明被否决的选项及其不足
组织ADR的存储与格式
将ADR作为文本文件存入项目仓库，便于版本控制和追溯。常用方式：
- 在项目根目录创建/docs/adrs或/adr文件夹
- 使用Markdown格式命名文件，如001-use-webpack-over-vite.md
- 文件名前缀加序号，便于排序和引用
- 可配合模板生成工具（如adr-tools）提升一致性
建立团队协作机制
ADR不是个人笔记，而是团队共识的体现。需要：
立即学习“前端免费学习笔记（深入）”；
- 在PR或会议中评审重要ADR，确保关键成员知情
- 鼓励新人阅读历史ADR，快速理解项目现状
- 当技术环境变化时，更新ADR状态（如从“已采纳”改为“已废弃”）
- 定期回顾ADR，识别过时决策或技术债源头
结合实际场景举例
例如某项目决定引入TypeScript：
- 背景：JavaScript项目逐渐复杂，类型错误频发
- 决策：逐步迁移至TypeScript
- 理由：提升代码可读性、减少运行时错误、IDE支持更好
- 影响：需配置ts-loader，增加编译时间，开发者需学习TS语法
- 替代方案：使用JSDoc + ESLint（检查力度较弱）
基本上就这些。保持ADR简洁、真实、可查，它就会成为项目演进的可靠日志。不复杂但容易忽略的是坚持写——哪怕只是一段话，也比没有强。
