1. 从“rea”这个标题说起：一个被低估的通用缩写
第一次看到“rea”这个标题，我脑子里蹦出来的第一反应是——这大概率是个缩写，而且是个被过度使用的缩写。做项目久了你会发现，越是简短的标题，背后藏的东西往往越多。“rea”这三个字母，在不同圈子里指向完全不同的东西：做前端的人看到它，第一反应是 React 生态里那些以 rea 开头的工具链；做数据处理的人看到它，会想到 real-time analytics（实时分析）；做硬件和嵌入式的人看到它，可能联想到 read、reactive、real-time 这些词根；而做业务系统的人，脑子里浮现的可能是 reconciliation（对账）、realtime（实时）、甚至 resource（资源）这类模块命名。
我之所以要花篇幅先把这个标题拆开讲，是因为一个项目的命名方式，往往暴露了作者的技术背景和这个项目要解决的核心问题。用三个字母做标题，通常意味着两件事：要么这是一个内部工具，作者默认读者知道上下文；要么这是一个高度聚焦的模块，功能单一到不需要更多解释。不管是哪种情况，作为接手或复现这个项目的人，第一步都不是急着写代码，而是先搞清楚“rea”到底指什么。
这篇博文我会围绕“rea”这个标题，把它可能对应的几类典型项目场景拆开讲透。核心不是给你一个标准答案，而是给你一套从模糊标题反推项目全貌的方法论，再配上可以直接抄作业的实操步骤。适合谁看？如果你手上正好有一个标题含糊、文档缺失、需要自己啃下来的项目，或者你自己想做一个以“rea”命名的模块却不知道该怎么设计，那这篇内容应该能帮你省下不少试错时间。
我个人的判断是，绝大多数以“rea”命名的项目，最终都落在三个方向之一：实时（realtime）、响应式（reactive）、对账/核对（reconciliation）。下面我按这三个方向分别展开，每个方向都给出设计思路、核心实现和踩坑记录。
2. 方向一：实时数据处理模块的设计与实现
2.1 为什么“实时”是最常见的落点
“rea”作为 realtime 的缩写，是我见过最多的用法。原因很简单：实时这个词在项目命名里太常用了，而 realtime 拼写又长，很多人图省事就砍成 rea。这类项目通常出现在数据管道、监控系统、消息处理这些场景里。
实时模块的核心诉求只有一个：数据从产生到被处理，延迟要尽可能低。但“低”是个相对概念。我做过的一个项目里，业务方说“要实时”，结果一问，他们能接受 5 秒的延迟。另一个项目里，业务方说“准实时就行”，结果要求 200 毫秒内出结果。所以第一步永远是把“实时”量化成具体数字，否则后面所有的技术选型都是瞎猜。
量化的维度有三个：延迟上限、吞吐量、数据乱序容忍度。延迟上限决定了你用流式还是微批；吞吐量决定了单机还是集群；乱序容忍度决定了你要不要引入水位线（watermark）机制。这三个参数定不下来，架构就没法定。
2.2 核心架构选型：流式还是微批
实时处理绕不开一个经典选择：真流式（streaming）还是微批（micro-batch）。我用一个生活化的类比来解释区别。真流式就像水龙头，水一滴一滴流出来，你随时接随时处理；微批就像用桶接水，每接满一小桶倒一次，处理的是“一小批”数据。
真流式的代表思路是事件驱动，每条数据来了立刻处理，延迟可以做到毫秒级，但状态管理和容错复杂。微批的代表思路是攒一小段时间（比如 1 秒）的数据一起处理，延迟通常在秒级，但实现简单、吞吐高、容错容易。
我的经验是：延迟要求低于 500 毫秒，选真流式；高于 1 秒，微批更划算。中间地带看团队技术栈，如果团队对状态管理不熟，宁可牺牲一点延迟选微批，也别硬上流式然后被容错问题拖垮。
下面是一个微批处理的简化实现，用 Python 演示核心逻辑：
import time from collections import deque class MicroBatchProcessor: def __init__(self, batch_size=100, flush_interval=1.0): self.batch_size = batch_size self.flush_interval = flush_interval self.buffer = deque() self.last_flush = time.time() def push(self, record): self.buffer.append(record) # 两个触发条件：攒够数量 或 到达时间窗口 if len(self.buffer) >= self.batch_size: self._flush() elif time.time() - self.last_flush >= self.flush_interval: self._flush() def _flush(self): if not self.buffer: return batch = list(self.buffer) self.buffer.clear() self.last_flush = time.time() self._process(batch) def _process(self, batch): # 实际处理逻辑，这里用打印代替 print(f"处理一批数据，共 {len(batch)} 条")这段代码的关键在于双触发条件：数量够了就处理，时间到了也处理。只用一个条件会出问题——如果数据量很小，只等数量触发，那这批数据可能永远攒不够，延迟无限大；如果只等时间触发，数据量突然暴涨时缓冲区会撑爆内存。两个条件同时用，才能兼顾延迟和内存。
2.3 状态管理与容错：实时系统最容易翻车的地方
实时模块一旦涉及“跨数据计算”，比如统计最近 5 分钟的订单总额，就必须引入状态。状态管理是实时系统里最容易翻车的部分，我踩过的坑基本都在这。
第一个坑是状态无限增长。比如你要统计“每个用户的累计消费”，如果用户量很大且从不清理，状态会越堆越大，最后内存爆掉。解决办法是给状态设过期时间（TTL），或者用窗口机制把状态限定在固定时间范围内。
第二个坑是重启后状态丢失。进程一重启，内存里的状态全没了，之前算的一半数据白算。解决办法是把状态定期持久化到外部存储，重启时从最近的检查点恢复。这里有个细节：检查点的频率要权衡，太频繁影响性能，太稀疏恢复时重算的数据多。
第三个坑是乱序数据导致结果错误。数据在网络里传输，到达顺序和产生顺序往往不一致。比如用户先下单后取消，但取消的消息可能先到。如果不处理乱序，你会先看到取消、后看到下单，逻辑就乱了。解决办法是引入水位线，等一段时间再处理，给迟到的数据一个缓冲期。
提示：水位线的等待时间不是拍脑袋定的，要看实际数据的乱序程度。我通常的做法是先跑一周，统计数据到达延迟的分布，取 95 分位数作为水位线等待时间。
2.4 实操心得：实时模块的三个反直觉经验
做了几个实时项目后，我总结出三条和直觉相反的经验，分享出来供参考。
第一条：不要追求极致的低延迟。很多人一上来就想把延迟压到最低，结果架构复杂到没人维护得动。实际上，把延迟从 100 毫秒降到 10 毫秒，业务价值可能微乎其微，但开发和运维成本翻好几倍。先满足业务要求，再考虑优化。
第二条：监控比处理逻辑更重要。实时系统出问题时，往往不是处理逻辑错了，而是数据积压、延迟飙升、状态异常这些运行时问题。没有完善的监控，你根本不知道系统已经出问题了。我习惯在实时模块里埋三类指标：输入速率、处理延迟、积压量。这三个指标一画出来，系统健康度一目了然。
第三条：降级方案要提前设计。实时系统不可能永远不出问题，关键是出问题时能不能优雅降级。比如处理不过来时，是丢弃部分数据还是降级成批处理？这个决策要在设计阶段就想清楚，别等线上炸了才临时拍板。
3. 方向二：响应式编程在前端的落地实践
3.1 响应式到底解决了什么问题
“rea”作为 reactive 的缩写，在前端圈子里非常常见。响应式编程的核心思想是：数据变了，依赖它的东西自动更新，你不用手动去通知。这听起来很美好，但很多人用响应式用出了 bug，根本原因是没理解它的适用边界。
我用一个类比来说明。传统命令式编程就像你手动开关灯：你想让灯亮，就去按开关。响应式编程就像声控灯：你发出声音（数据变化），灯自动亮。好处是你不用关心“谁该亮”，坏处是如果声音太杂（数据变化太频繁），灯会闪个不停。
所以响应式的第一个关键点是控制数据变化的频率。我见过一个项目，把鼠标移动的坐标做成了响应式数据，结果每次移动都触发一堆计算，页面卡到没法用。后来改成节流（throttle），每 100 毫秒才更新一次，问题就解决了。
3.2 依赖追踪的实现原理
响应式最核心的机制是依赖追踪：系统要知道“谁依赖了谁”，才能在数据变化时精准通知。实现方式通常有两种：手动声明依赖和自动收集依赖。
手动声明依赖就是你自己写清楚“A 依赖 B”，简单直接但容易漏。自动收集依赖是在读取数据时记录“当前谁在读我”，写入时通知所有读过我的地方。后者更智能，但实现复杂，也是大多数响应式框架采用的方式。
下面用 JavaScript 演示一个极简的自动依赖追踪实现：
// 当前正在执行的副作用函数 let activeEffect = null; // 依赖收集表：target -> key -> effects const targetMap = new WeakMap(); function track(target, key) { if (!activeEffect) return; let depsMap = targetMap.get(target); if (!depsMap) { depsMap = new Map(); targetMap.set(target, depsMap); } let effects = depsMap.get(key); if (!effects) { effects = new Set(); depsMap.set(key, effects); } effects.add(activeEffect); } function trigger(target, key) { const depsMap = targetMap.get(target); if (!depsMap) return; const effects = depsMap.get(key); if (effects) { effects.forEach(effect => effect()); } } function reactive(obj) { return new Proxy(obj, { get(target, key) { track(target, key); return target[key]; }, set(target, key, value) { target[key] = value; trigger(target, key); return true; } }); } function effect(fn) { activeEffect = fn; fn(); // 执行一次，触发依赖收集 activeEffect = null; }这段代码虽然简化，但把响应式的核心机制讲清楚了：读取时收集依赖，写入时触发更新。理解了这一点，再看各种响应式框架的源码就不会觉得神秘了。
3.3 响应式的性能陷阱与规避
响应式用不好，性能问题比命令式还严重。我总结了几类常见的性能陷阱。
第一类是过度响应。不是所有数据都需要响应式。比如一个只用于展示、从不变化的配置对象，把它做成响应式纯属浪费。判断标准很简单：这个数据会不会变？变了之后有没有东西需要跟着更新？两个都是“是”，才需要响应式。
第二类是响应链路过长。A 变触发 B，B 变触发 C，C 变触发 D……链路越长，一次变化引发的计算越多。我见过一个项目，一个输入框的值变化，触发了十几层连锁更新，输入都卡顿。解决办法是扁平化依赖关系，能直接依赖的不要绕弯。
第三类是副作用不清理。响应式副作用如果注册了却不注销，会一直存在，造成内存泄漏。特别是在组件销毁时，一定要记得清理相关的副作用。这个坑我在实际项目里踩过，页面来回切换几次后内存就涨上去了，排查半天才发现是副作用没清理。
3.4 什么时候不该用响应式
响应式不是银弹，有些场景用它反而添乱。
一次性计算不适合响应式。比如页面加载时算一次总数，之后不再变化，用普通函数调用就行，没必要做成响应式。
高频变化且无需精确响应的场景不适合。比如滚动位置，你不需要每次滚动都精确响应，用节流加普通变量就够了。
跨模块的复杂状态共享要谨慎。响应式在小范围内很好用，但一旦状态被多个模块共享，依赖关系会变得难以追踪。这时候更适合用明确的状态管理方案，而不是靠响应式自动追踪。
注意：响应式的调试难度比命令式高。因为更新是自动触发的，出问题时你很难一眼看出“是谁触发了这次更新”。建议在开发阶段加上依赖关系的可视化工具，能省很多排查时间。
4. 方向三：对账与核对系统的工程化实现
4.1 对账系统的核心难点
“rea”作为 reconciliation 的缩写，在金融、电商、支付这类业务系统里很常见。对账的本质是拿两份数据比对，找出不一致的地方。听起来简单，但工程实现上有几个硬骨头。
第一个难点是数据量。对账往往是全量比对，两份数据可能都是千万甚至亿级别。全量加载到内存里比对，内存直接爆。必须用分块、流式或者基于排序的比对算法。
第二个难点是数据格式不一致。A 系统的金额是分，B 系统的金额是元；A 系统的时间是时间戳，B 系统的时间是字符串。对账前必须先做标准化，否则比出来的全是差异。
第三个难点是差异分类。两份数据不一致，原因可能有很多：一边多、一边少、金额对不上、状态对不上。不同的差异要不同处理，不能笼统地报“不一致”。
4.2 分块对账的实现思路
针对大数据量，我常用的方案是按主键分块，逐块比对。核心思路是把两份数据按同一个主键排序，然后像拉链一样同步推进，遇到不一致就记录。
def reconcile(left_records, right_records, key_func): """ 对两份已按主键排序的数据做对账 返回差异列表 """ diffs = [] i, j = 0, 0 while i < len(left_records) and j < len(right_records): left_key = key_func(left_records[i]) right_key = key_func(right_records[j]) if left_key == right_key: # 主键相同，比对内容 if left_records[i] != right_records[j]: diffs.append({ 'type': 'content_mismatch', 'key': left_key, 'left': left_records[i], 'right': right_records[j] }) i += 1 j += 1 elif left_key < right_key: # 左边有，右边没有 diffs.append({ 'type': 'left_only', 'key': left_key, 'left': left_records[i] }) i += 1 else: # 右边有，左边没有 diffs.append({ 'type': 'right_only', 'key': right_key, 'right': right_records[j] }) j += 1 # 处理剩余 while i < len(left_records): diffs.append({'type': 'left_only', 'key': key_func(left_records[i]), 'left': left_records[i]}) i += 1 while j < len(right_records): diffs.append({'type': 'right_only', 'key': key_func(right_records[j]), 'right': right_records[j]}) j += 1 return diffs这个算法的好处是只需要同时持有两条记录，内存占用极低，而且时间复杂度是线性的。前提是数据已经排好序，排序可以交给数据库或者外部排序完成。
4.3 差异处理与人工介入
对账系统跑出差异只是第一步，怎么处理差异才是真正花时间的部分。我的经验是把差异分成三类，分别处理。
第一类是可自动修复的差异。比如一边有记录一边没有，但能通过其他字段匹配上，这种可以自动补全。自动修复要记录日志，方便事后审计。
第二类是需要人工确认的差异。比如金额对不上，但差异很小，可能是手续费计算方式不同。这种要生成工单，让人来判断。
第三类是必须告警的差异。比如大额差异、批量差异，这种往往意味着系统出了问题，要立刻通知相关人员。
提示：对账系统一定要有“重跑”能力。第一次跑出差异，人工处理了一部分，剩下的想重新跑一遍，系统要支持。我见过不支持重跑的对账系统，每次都要从头全量跑，慢得要命。
4.4 对账系统的监控与告警
对账系统本身也需要监控。我关注几个指标：对账耗时、差异数量、差异率、自动修复成功率。差异数量突然飙升，往往意味着上游系统出了问题；自动修复成功率下降，说明修复规则可能失效了。
告警的阈值设置要结合历史数据。比如平时差异率是万分之一，突然变成百分之一，那肯定要告警。但如果业务本身就有波动，阈值设太死会天天误报。我的做法是用移动平均加标准差，动态调整阈值。
5. 从“rea”反推项目全貌的方法论
5.1 三步定位法
讲了三个方向，回到最初的问题：拿到一个叫“rea”的项目，怎么快速判断它属于哪一类？我总结了一个三步定位法。
第一步，看依赖。打开项目的依赖清单，如果看到 React、Vue、Svelte 这类前端框架，大概率是响应式方向；如果看到 Kafka、Flink、Spark Streaming，大概率是实时方向；如果看到数据库驱动、定时任务框架，可能是对账方向。
第二步，看目录结构。实时项目通常有 producer、consumer、processor 这类目录；响应式项目通常有 components、hooks、store；对账项目通常有 comparator、matcher、report 这类目录。
第三步，看入口文件。入口文件里如果是一个持续运行的循环，那是实时；如果是事件监听和渲染，那是响应式；如果是定时触发加批量处理，那是对账。
这三步走下来，基本能定位个八九不离十。
5.2 命名背后的团队习惯
项目的命名方式还能反映团队习惯。用三个字母缩写的团队，通常追求简洁、内部沟通成本低，但缺点是新人上手门槛高。这类项目往往文档也少，因为作者觉得“这么简单还需要写文档？”
遇到这种项目，我的建议是先别急着改代码，先补文档。把你自己理解的项目全貌写下来，和原作者确认。这个过程既能帮你理清思路，也能暴露理解偏差。我接手过好几个这种“三字母项目”，补文档花的时间比写代码还多，但非常值得。
5.3 接手模糊项目的通用清单
最后给一份接手模糊项目的通用清单，可以直接拿去用。
- 确认项目全称和核心功能，别猜，直接问
- 找到并运行测试用例，测试是最好的文档
- 画出数据流图，标出输入、处理、输出
- 识别外部依赖，搞清楚每个依赖的作用
- 找到配置项，理解每个配置的含义
- 定位核心逻辑，通常只占代码量的 20%
- 记录所有疑问，集中找原作者确认
这份清单看着简单，但真按这个走一遍，再模糊的项目也能摸清楚。我在实际使用中发现，最容易忽略的是“运行测试用例”这一步。很多人上来就读代码，读得云里雾里，其实跑一遍测试，输入输出一目了然，比读半天代码管用多了。
6. 通用实操：搭建一个可复用的“rea”模块骨架
6.1 目录结构设计
不管你最终做的是哪个方向的“rea”项目，一个清晰的目录结构都能省很多事。我常用的骨架是这样的：
rea/ ├── config/ # 配置 │ ├── default.yaml │ └── production.yaml ├── core/ # 核心逻辑 │ ├── processor.py │ └── state.py ├── adapters/ # 外部适配 │ ├── input.py │ └── output.py ├── utils/ # 工具函数 │ ├── logger.py │ └── metrics.py ├── tests/ # 测试 │ ├── test_processor.py │ └── fixtures/ └── main.py # 入口这个结构的好处是职责清晰：core 放纯逻辑，不依赖外部；adapters 负责和外部系统打交道；config 集中管理配置。这样 core 部分可以单独测试，不依赖真实的外部环境。
6.2 配置管理的最佳实践
配置管理有个常见误区：把所有配置都写死在代码里，或者全塞进环境变量。我的做法是分层配置：默认配置写在代码里，环境相关配置放配置文件，敏感信息放环境变量。
import os import yaml class Config: def __init__(self, config_path=None): self._data = self._load_defaults() if config_path: self._data.update(self._load_file(config_path)) self._data.update(self._load_env()) def _load_defaults(self): return { 'batch_size': 100, 'flush_interval': 1.0, 'log_level': 'INFO' } def _load_file(self, path): with open(path, 'r') as f: return yaml.safe_load(f) or {} def _load_env(self): # 环境变量覆盖，前缀 REA_ overrides = {} for key, value in os.environ.items(): if key.startswith('REA_'): config_key = key[4:].lower() overrides[config_key] = value return overrides def get(self, key, default=None): return self._data.get(key, default)分层的好处是优先级明确：环境变量 > 配置文件 > 默认值。部署时改环境变量就行，不用动配置文件。
6.3 日志与监控的埋点
日志和监控是项目可维护性的关键。我的习惯是在项目初期就把日志和监控埋好，别等出问题了才加。
日志分三个级别用：DEBUG 用于开发排查，INFO 记录关键流程，ERROR 记录异常。生产环境一般开 INFO，出问题时临时调到 DEBUG。
监控埋点我关注四类：输入量、输出量、处理耗时、错误数。这四个指标能覆盖大部分运行时问题。埋点代码要轻量，别因为埋点本身影响性能。
import time import logging logger = logging.getLogger(__name__) class Metrics: def __init__(self): self.counters = {} self.timers = {} def incr(self, name, value=1): self.counters[name] = self.counters.get(name, 0) + value def observe(self, name, duration): if name not in self.timers: self.timers[name] = [] self.timers[name].append(duration) def report(self): for name, value in self.counters.items(): logger.info(f"counter {name}={value}") for name, values in self.timers.items(): if values: avg = sum(values) / len(values) logger.info(f"timer {name} avg={avg:.3f} count={len(values)}")6.4 测试策略：从单元到集成
测试是保证项目质量的底线。我的测试策略分三层：单元测试覆盖核心逻辑，集成测试覆盖模块间交互，端到端测试覆盖完整流程。
单元测试要快，不依赖外部环境，用 mock 替代外部调用。集成测试可以慢一点，但要覆盖真实的交互路径。端到端测试最慢，只在关键流程上做。
测试数据的管理也很重要。我习惯把测试数据放在 fixtures 目录里，用 YAML 或 JSON 格式，方便阅读和修改。测试数据要覆盖正常情况、边界情况、异常情况三类。
提示：测试用例的命名要能说明意图。
test_process_normal比test1好，test_process_empty_input比test2好。测试失败时，光看名字就知道哪里出了问题。
7. 常见问题与排查技巧实录
7.1 实时方向常见问题
问题一：数据积压，延迟越来越高。排查思路是先看输入速率是不是突然涨了，再看处理速率是不是降了。如果输入涨了，考虑扩容；如果处理降了，看是不是某个环节卡住了。我遇到过一次，是因为下游写入变慢，导致整个管道堵住。解决办法是给下游写入加超时和重试，避免一个慢节点拖垮全局。
问题二：重启后数据重复处理。这是检查点机制没做好。重启时应该从最近的检查点恢复，而不是从头开始。如果检查点记录的是“处理到哪条数据”，重启后从那条之后继续就行。如果记录的是“处理到哪个时间点”，要注意时间点附近的数据可能重复，需要下游做幂等。
问题三：状态越来越大。先确认状态是不是有必要保留这么久。很多状态其实只需要保留最近一段时间的，设个 TTL 就能解决。如果确实需要长期保留，考虑把状态放到外部存储，别全放内存。
7.2 响应式方向常见问题
问题一：更新不触发。最常见的原因是依赖没收集到。比如你在响应式数据外面套了一层普通对象，读取时经过的是普通对象，依赖就收集不到。解决办法是确保读取路径上都是响应式对象。
问题二：更新触发太频繁。用节流或防抖控制频率。另外检查是不是有不必要的依赖，比如一个计算属性依赖了一个很少用到的数据，可以把它拆出来。
问题三：内存泄漏。检查副作用有没有清理。组件销毁、页面切换时，相关的副作用要注销。用工具监控内存变化，如果内存持续增长不回落，基本就是泄漏了。
7.3 对账方向常见问题
问题一：对账跑不完。数据量太大，全量加载内存爆了。改用分块或流式比对。如果数据库支持，直接用 SQL 做 join 比对，比拉到应用层快得多。
问题二：差异太多，看不过来。先做差异分类和聚合。比如按差异类型分组，按金额区间分组，先看大额差异和批量差异。很多小额差异可能是同一个原因，处理一个规则就能批量解决。
问题三：对账结果不稳定。每次跑出来的差异不一样，说明数据在变。对账要基于一个固定的时间点快照，别用实时变化的数据。如果数据源不支持快照，至少要把对账期间的数据变更记录下来，事后核对。
7.4 问题排查速查表
| 现象 | 可能原因 | 排查方向 | 解决思路 |
|---|---|---|---|
| 延迟飙升 | 输入涨/处理降/下游堵 | 看速率指标 | 扩容或优化瓶颈 |
| 数据重复 | 检查点机制问题 | 看恢复逻辑 | 加幂等或修正检查点 |
| 内存增长 | 状态未清理/副作用泄漏 | 看内存曲线 | 加 TTL 或清理副作用 |
| 更新不触发 | 依赖未收集 | 看读取路径 | 确保响应式对象 |
| 对账跑不完 | 数据量太大 | 看内存占用 | 分块或流式比对 |
| 差异不稳定 | 数据在变化 | 看数据源 | 用快照或记录变更 |
这张表是我这些年排查问题的经验浓缩，遇到问题先对照着看，能省不少时间。当然，实际问题往往比表格复杂，但有个起点总比瞎猜强。
8. 一些踩坑之后的个人体会
做项目这些年，我越来越觉得标题模糊不是问题，问题是懒得去搞清楚它到底指什么。“rea”这三个字母，可以是实时、响应式、对账，也可以是别的什么。重要的不是猜对它是哪个，而是掌握一套从模糊到清晰的方法。
我自己的习惯是，拿到任何项目，先花半天时间只做一件事：搞清楚它是什么、解决什么问题、怎么跑起来。这半天不写一行代码，就是读、问、跑。很多人觉得这是浪费时间，急着上手改代码，结果改了半天发现方向都错了。我踩过这个坑，后来就学乖了，宁可前期慢一点，也要先把全貌摸清楚。
另一个体会是，通用骨架比具体实现更值钱。这篇博文里给的目录结构、配置管理、日志埋点、测试策略，不管你最终做的是哪个方向的“rea”，都能直接套用。具体业务逻辑每个项目都不一样，但这些工程化的东西是相通的。把骨架搭好，往里填业务逻辑就快了。
最后分享一个小技巧：给项目写一份“给三个月后的自己看”的文档。三个月后你肯定忘了当初为什么这么设计，这份文档能帮你快速回忆起来。文档不用长，把关键决策和原因写清楚就行。这个习惯帮我省了无数次重新读代码的时间。
