事情是在一次看似普通的同步会上被点破的。
会议没有标题为“风险”，
也没有任何预警。
只是陈浩在最后翻了一页 PPT，
停了一下。
“有个问题，”他说，“我想听听你们的真实判断。”
会议室里很安静。
投影上只有一行字：
阅读器：后续维护成本评估
没有红字，
没有加粗。
但林晨的注意力一下子被拉紧了。
“我们现在的实现，”陈浩继续说，“功能上没问题，性能也在可控范围。”
“但我想问一句——
如果三个月后需求翻倍，这套结构还能不能撑？ ”
这不是质疑。
是典型的技术负责人问未来的方式。
林晨没有立刻回答。
他在脑子里快速过了一遍最近几天改过的地方：
-
watch 拆分
-
响应范围收紧
-
滚动与样式解耦
这些优化解决的是当下问题。
但陈浩问的是：
增长之后呢？****
“现在这套，”林晨开口了，“是‘还能用’，但不是‘为变化准备的’。”
苏雨侧头看了他一眼。
这句话，比“有风险”要重。
张明接话：“具体指哪？”
林晨站起身，走到白板前。
他没有画架构图，
而是写了一个非常简单的东西。
阅读器 = 内容 + 状态 + 行为
“我们现在的问题不在‘功能’，”他说，“在边界不够清晰。”
他写下第二行：
状态 ≈ 一切
“目前，
阅读进度、样式设置、章节索引、UI 显隐，
都在同一套响应系统里。”
“好处是——快。”
“坏处是——
任何变化，都会被放大。 ”
苏雨皱了下眉。
“但这样不是很方便吗？”她问，“改一个地方，UI 自动更新。”
“是。”林晨点头，“在需求稳定的时候，这是最省事的方式。”
“但当需求开始变化——
比如：
-
多端同步
-
阅读统计
-
标注、高亮
-
评论或协作阅读”
“这些都会往状态系统里继续塞东西。”
他在白板上补了一句： 响应式 ≠ 免费
空气安静了一瞬。
陈浩笑了一下。
“这句话我喜欢。”
他转向苏雨：“你怎么看？”
苏雨想了一会儿。
“我承认，”她说，“我之前更关心‘能不能快点实现’，而不是‘以后好不好改’。”
“但从产品角度，如果我们真要把阅读器当成长期模块，
那后续功能几乎是必然的。”
她停顿了一下。
“那你觉得，现在的问题该叫什么？”
林晨没有绕。
“技术债。”
不是贬义，
也不是指责。
是一个阶段性事实。
他补了一句：“不是‘写得不好’，而是为了速度，提前透支了结构弹性。”
这是一个很工程师的定义。
陈浩点头。
“那问题就变成了，”他说，“我们现在要不要还？”
会议进入真正的核心。
林晨没有直接说“要”。
他先说代价。
“如果现在不还，”他说，“短期内没问题。”
“但等到功能叠加，
我们会开始害怕改代码。”
“害怕不是因为复杂，
而是因为不知道改哪里会牵一发而动全身。”
他在白板上写了一个例子。
// 当前
watch(allState, () => updateUI())
// 理想
watch(readingSettings, updateStyle)
watch(readingProgress, saveProgress)
“区别不在 API，
在责任边界。”
苏雨看着那两段代码，忽然说了一句：
“所以，
现在不还，
其实是在把选择权推给未来的自己。”
林晨看了她一眼。
这不是产品经理常说的话。
但很准。
最终的决定不是立刻重构。
而是一个折中的版本。
陈浩拍板：
-
本期不大改结构****
-
新增功能前，必须评估是否扩大技术债****
-
下一个大版本，预留一次架构调整窗口
“技术债不是原罪，”他说，“
不承认，才是。 ”
会散了。
人陆续离开会议室。
林晨收拾电脑时，苏雨还坐着。
“你刚才说的那些，”她开口，“其实挺反直觉的。”
“怎么说？”
“我以前觉得，
技术的价值在于‘解决问题’。”
她抬头看他。
“但你今天说的，更像是——
控制问题的扩散。 ”
林晨想了想。
“系统做大之后，
解决问题反而是小事。”
“真正难的是，
不让问题变成一团。”
苏雨点点头。
“那以后我提需求的时候，
可能会多问一句：
这个东西，会不会让系统更难解释。”
“那就太好了。”
林晨笑了一下。
那天晚上，他在 README 里加了一小节。
标题很朴素：
Architecture Notes
里面只有几句话：
-
响应式用于表达“状态”，不是“一切变化”
-
滚动、动画、阅读行为，优先走浏览器能力
-
新功能优先问：它属于哪个边界？
没有人要求他写。
但他知道，
这是一种对未来同事的解释。****
技术债被点名的那一刻，
并没有爆炸。
它只是被放在了桌上。
但从那天起，
这个项目不再只是“能跑”。
它开始被当成——
一个需要被长期对待的系统。
