<!--
这是架构模板的统一格式。复制本文件,把每一段填满。
两条铁律:
  1) 只讲架构,不讲语言/框架/具体库。出现「用 X 语言的 Y 库」就改写成架构层面的描述
     (例:不写「用 Redis」,写「用内存级 KV 缓存」并在权衡里说明为什么这类存储)。
  2) 图一律用 ASCII(纯文本框线),保证任何地方都能看、永不失效。
方括号 [ ] 里是写作提示,填写时删掉。
-->

# [系统名称] 架构模板

> **代表产品**:[Claude / Honey / ...]
> **一句话定位**:[用一句话说清这是什么系统]

---

## 1. 一句话定位

[一句话。读者看完这句,应该立刻知道这是个什么东西、和它最像的产品是谁。]

## 2. 业务本质:它在解决什么问题

[抛开技术,先说人话:这类系统为谁、解决什么痛点、靠什么赚钱或创造价值。
架构的所有取舍最终都服务于业务本质——讲清这个,后面的设计才有依据。]

## 3. 核心需求与约束

把需求拆成两类。**这是架构师最重要的基本功:区分「功能」和「质量」。**

**功能性需求(系统要能做什么):**
- [ ] [核心功能 1]
- [ ] [核心功能 2]

**非功能性需求 / 质量属性(系统要做得多好):**
| 质量属性 | 目标 | 为什么对这类系统重要 |
|---|---|---|
| [如 延迟] | [如 首字 < 1s] | [原因] |
| [如 可用性] | [如 99.9%] | [原因] |

**关键约束(不可逾越的边界):**
- [如 成本、合规、团队规模、第三方依赖、物理限制]

## 4. 架构全景图

```
[用 ASCII 画一张整体架构图。要求:
 - 能看出分层 / 模块边界
 - 标出数据流方向(用箭头)
 - 标出外部依赖(第三方、用户、设备)
 - 不要追求面面俱到,要突出「这个系统的灵魂部件」]
```

## 5. 组件职责

逐个说明上图里每个关键部件**做什么 + 为什么需要它**(没有「为什么」的部件就是过度设计)。

- **[组件 A]**:[职责]。*为什么需要*:[理由]。
- **[组件 B]**:[职责]。*为什么需要*:[理由]。

## 6. 关键数据流

挑 2–3 个**最能体现这个系统特点**的场景,画出请求/数据怎么一步步流动。

**场景一:[如「用户发一条消息」]**
```
[用编号步骤或 ASCII 时序,画出从入口到落库/返回的完整路径]
1. ...
2. ...
```

**场景二:[另一个核心场景]**
```
...
```

## 7. 数据模型与存储选择

[这类系统的核心数据是什么(实体 + 关系的概念模型,不写建表语句)。
不同数据为什么放在不同类型的存储里(关系型 / 文档 / KV / 列存 / 对象存储 / 搜索 / 时序…)。
重点讲「为什么这种数据适合这种存储」,而不是用哪个产品。]

| 数据 | 存储类型 | 为什么 |
|---|---|---|
| [如 用户资料] | [关系型] | [需要事务/强一致] |
| [如 消息内容] | [对象存储] | [大、不变、按 ID 取] |

## 8. 关键架构决策与权衡 ⭐

**(本模板最值钱的一节。)** 列出几个真正的「岔路口」,每个写清:面临的选择、最终取向、放弃了什么。

**决策 1:[决策点,如「Feed 用推模型还是拉模型」]**
- 选项 A:[…],优点 […],代价 […]
- 选项 B:[…],优点 […],代价 […]
- **取向**:[通常怎么选],因为 [关键约束]。

**决策 2:[…]**
...

## 9. 规模化与瓶颈

[随着用户/数据/流量增长,**第一个会撑不住的地方在哪**?然后是第二个?
针对每个瓶颈,通常的破解手段是什么(分片、缓存、异步、读写分离、CDN…)?
这一节回答:从 1 万用户到 1 亿用户,架构会怎么变。]

- **第一个瓶颈**:[…] → 破解:[…]
- **下一个瓶颈**:[…] → 破解:[…]

## 10. 安全与合规要点

[这类系统的主要攻击面 / 风险在哪?哪些数据是敏感的、碰了会出大事(隐私、支付、合规)?
架构上怎么设边界(隔离、最小权限、加密、审计)?]

## 11. 常见误区 / 反模式

[新手做这类系统时最容易犯的架构错误。每条写「错误做法 → 为什么错 → 正确思路」。
这一节是「别人踩过的坑」,极其宝贵。]

- ❌ [常见错误] → ✅ [正确思路]

## 12. 演进路线:MVP → 成长期 → 成熟期

架构是会长大的。**别拿成熟期的图去套 MVP。**

| 阶段 | 用户/规模量级 | 架构长什么样 | 此时该操心什么 |
|---|---|---|---|
| **MVP** | [如 < 1万] | [最简形态,可能就是个单体] | [先验证需求,别过度设计] |
| **成长期** | [如 百万级] | [开始拆分/加缓存/异步化] | [找瓶颈、保稳定] |
| **成熟期** | [如 亿级] | [分片/多活/专用子系统] | [成本、容灾、组织协同] |

## 13. 可复用要点

[这个模板里,哪些架构思想是**通用的**、可以搬到其它系统上的?
列 3–5 条「带得走的智慧」。]

- 💡 [可迁移的架构思想 1]
- 💡 [可迁移的架构思想 2]

## 14. 参考原型与延伸阅读

[本模板基于哪些**真实**的开源项目 / 公开工程博客 / 官方文档 / 论文?列出来并给**真实链接**。
 铁律:不要编造或臆想链接——只放你**查证过、真实存在**的;优先官方开源仓库与官方工程博客。
 每条写「`[名称](URL)` — 一句话:它是什么 + 体现了本模板哪个要点」。]

**🔧 开源原型(可直接读代码):**
- [项目名](https://github.com/org/repo) — [一句话:体现了哪个核心点]。

**📖 工程博客 / 官方文档 / 论文:**
- [标题](https://...) — [它讲了什么、对应本模板哪一节]。

---

> 📌 用本模板时记住:**读者要带走的是「为什么」,不是「有几个框」。** 每个设计都要能回答「它在换取什么」。