上周组里一个产品上线前的合规评审会上，合规专员盯着一段前端代码问了一个问题："这个收益率计算逻辑，用户在购买前看到的结果和购买后持仓页显示的结果，走的是不是同一条计算链路？"

在场的两个前端工程师面面相觑。答案是"不是"。购买前用的是推荐接口的预计算数据，持仓页用的是资产接口的实时结算数据。两条链路，两套精度处理，两组四舍五入规则。在普通业务里这根本不算事——数据来源不同，展示逻辑不同，非常自然。但在金融业务里，这意味着用户可能看到购买前年化3.52%，购买后变成3.51%。

0.01%的偏差，万亿规模下就是上亿的资金差异预期。合规专员当场拍了桌子，上线延期两周。

这个场景在互联网公司几乎不会发生。但在金融科技团队，它是日常。

金融业务的代码有两套读者

大部分工程师写代码时心里只有一个读者：运行时环境。代码能不能跑，跑得快不快，内存占不占得住——所有的优化方向都指向机器。

金融业务的代码不一样。它有两套读者：机器和审计。而且讽刺的是，审计这个读者往往比机器更难伺候。机器只要逻辑正确就行，审计要的是"逻辑正确且可追溯且可解释且可复现"。多出来的这三个"且"，才是金融科技工程真正的成本。

DRY——Don't Repeat Yourself。这四个字母可能是软件工程里被引用最多、被误解最深的原则。

每个程序员入行第一天就被告知：重复代码是邪恶的，看到重复就要提取，看到提取就要抽象，看到抽象就要泛化。于是我们疯狂地消灭重复——公共函数、工具类、基础库、共享模块......代码库越来越"干净"，重复率越来越低，CI里没有任何duplicate code的警告。

然后某一天，一个业务需求来了——需要改动某个"公共"逻辑。你打开那个被47个地方引用的utils函数，改了一行，跑了一下测试——绿了。上线，结果三个业务线同时报警。你突然发现，那三个业务线依赖的是同一个函数的三种不同行为，被那个"公共"函数强制统一了。

你消灭了重复代码，但你制造了耦合。而耦合，是比重复贵十倍的技术债。

重复代码不是问题，问题是不知道为什么重复

所有关于DRY的讨论，都默认了一个前提：重复等于坏。但这个前提本身就是幻觉。

重复代码至少有三种完全不同的面目。

第一种是意外重复——两个开发者不知道对方写了同样的功能，造了两个轮子。这种重复才是真正需要消灭的，因为它意味着信息浪费和潜在的不一致。

打开任何一个前端项目的代码，搜索 `catch`，你大概率会看到这样的画面：

```javascript
try {
await fetchData();
} catch (e) {
console.error(e);
message.error('操作失败，请稍后重试');
}
```

后端也好不到哪去：

```javascript
try {
await processOrder(orderId);
} catch (err) {
logger.error('订单处理失败', { orderId, error: err.message });
throw new BusinessException('系统异常，请重试');
}
```

这两段代码有一个共同的特质——它们让你觉得错误被"处理"了。日志打了，提示也弹了，异常也抛了，一切看起来都很体面。

但你仔细想想：用户看到"操作失败，请稍后重试"之后能做什么？重试？然后呢——再失败一次？运维看到一条"订单处理失败"的日志，能定位到什么？是库存扣减超时，还是支付回调丢失，还是风控拦截？

前端的现状有点荒诞：我们嘴上说自己在写 UI，实际上大部分时间在跟数据较劲。Redux、Zustand、React Query、SWR、Dva、Pinia——每出一个新方案，大家就觉得"这次终于对了"。但如果你把所有这些方案放在一起，去掉它们的外壳看本质，会发现一个尴尬的事实：它们解决的问题，数据库几十年前就解决了，而且解决得更好。

我们不是在做状态管理，我们是在重新发明数据库。只是发明得很差。

一个 Redux Store 就是一个简化版数据库

Redux 可能是最明显的例子。你写一个 Redux store 的时候，本质上在做什么？

定义一个全局的数据结构——这叫 Schema。写 reducer 处理 action——这叫事务（Transaction），action 本身就是 WAL 日志。写 selector 查询数据——这叫查询引擎。写 middleware 拦截 action——这叫触发器（Trigger）。用 normalize 归一化数据——这不就是数据库范式吗？

前后端分离之后，我们发明了一个安慰自己的概念——"接口契约"。Swagger 文档一摆，TypeScript 类型一生成，团队觉得天上地下都對齐了：字段名对齐了，类型对齐了，必填选填对齐了。然后上线第一天就出了 bug——status 为 3 的情况前端压根没处理，amount 的单位后端返回的是分前端当成了元，createTime 在后端是 UTC 前端按本地时间解析了。

没错，类型是对上了。但类型对上和意思对上之间，隔的不是一行代码，是一个认知深渊。

接口文档给了我们一种虚假的安全感

我做过很多次前后端协作的接口评审，也主持过不少次。每次的流程都差不多：后端同事打开 Swagger 或 YApi，一个字段一个字段地过，前端同事点头说"收到"。大家都很认真，评审记录也写了，看起来协作很顺畅。

但评审过程有个微妙的问题——我们在确认的是"形状"，不是"语义"。

什么叫形状？`{ orderId: string, status: number, amount: number }` 这就是形状。字段名有了，类型有了，看起来很完整。但这句话里藏了多少没说清楚的东西？

做金融业务的前端，最常听到的抱怨就是"合规又来了"。每次需求评审，合规团队提出的数据隔离、操作留痕、访问控制要求，都像是在给工程师戴枷锁。我刚转金融业务那几年也是这么想的——好好的架构被合规要求弄得支离破碎，什么都要审计，什么都要脱敏，什么都要分权。

但做了几年之后，我发现一个反直觉的现象：那些被合规逼出来的设计，反而比"自由发挥"的架构更经得起时间考验。而那些早期没有合规约束、随意生长的系统，后来几乎没有一个不重构的。

这个观察让我重新理解了约束和设计的关系。

自由是设计的天敌

我见过两类系统的演化路径，差别很大。

第一类是金融业务系统。从第一天起就有明确约束：用户数据不能明文存储、敏感操作必须留审计日志、同一页面不同角色的数据要隔离、接口调用要有频率限制和幂等保证。这些约束在项目初期像紧身衣一样让人难受——写个列表页要考虑字段脱敏，做个按钮要判断权限再判断状态再判断是否可重复点击，发个请求要带traceId还要处理幂等。

第二类是内部工具和运营后台。没有合规约束，怎么方便怎么来。接口随便调，数据随便传，状态随便改，上线快、迭代快，大家都觉得效率高。

猜猜三年后哪个更健康？

每个产品经理都想要"实时"。实时报价、实时持仓、实时通知、实时风控——但凡跟"实时"沾边的需求，优先级都高得离谱。好像只要数据不是实时推送的，这个功能就不值得做。

但这里有个问题少有人追问：你看到的"实时"，到底实时到什么程度？

我见过太多团队在"实时"这两个字上栽跟头。不是技术做不出来，是做出来了才发现——用户根本分不清实时和准实时的区别，而团队却为那500毫秒的"实时"付出了整个架构的代价。

WebSocket的承诺和账单

先从最常见的"实时"方案说起。

WebSocket火了之后，几乎每个前端团队都想把长连接加上。HTTP轮询？那是不体面的技术债务。SSE？那是不完整的实时。只有全双工的WebSocket才配得上"实时"这两个字。

但WebSocket不是免费的午餐，它的账单分三层。

第一层是连接管理。一个WebSocket连接意味着服务端要维护一条持久化的TCP通道。听起来不复杂，但你算一下：10万个在线用户，10万条长连接，每条连接都有心跳、超时、重连逻辑。你的服务端不再是无状态的HTTP服务器了，它变成一个有状态的连接管理中心。这个转变的代价远比大多数团队预估的大。

2021年前后，微前端是前端圈最火的架构概念。qiankun、single-spa、Module Federation，各种方案轮番上阵，每过几个月就有一篇"微前端最佳实践"刷屏。团队的架构升级PPT里如果没挂一个微前端的示意图，都不好意思拿出来汇报。

三年过去了，真正在线上跑过微前端的人，大多有一种心照不宣的沉默：方案落地了，页面跑起来了，但总觉得哪里不对劲。

不对劲的地方，通常不在PPT里。

三个承诺和一个现实

微前端刚出来的时候，给了三个承诺：技术栈无关、独立部署、团队自治。每一个听起来都很美，每一个在实践中都打了折。

技术栈无关意味着子应用可以自由选择框架。React的团队用React，Vue的团队用Vue，听起来皆大欢喜。但"无关"只存在于第一个版本。三个月后，你会发现共享组件怎么办——A子应用用React写了一套表格组件，B子应用用Vue想要相同的交互，是再写一遍还是搞iframe嵌套？六个月后，你的招聘成本翻倍了，因为新人得同时熟悉两套技术栈的代码风格。一年后，某个子应用的技术栈要升级，但它和其他子应用之间的样式隔离出了问题——因为当初"无关"的时候，没人定义样式边界的规范。

技术栈无关真正的代价不是今天允许你自由选择，是明天让你无法统一收口。

每次做技术选型的时候，我都会想起期权定价模型。不是因为我爱装，是因为这玩意儿真的解释了大部分技术决策为什么会翻车。

做金融业务的人应该对这个逻辑不陌生——一个期权的价值，不取决于标的资产今天的价格，而取决于它未来的波动率、到期时间和执行价格。

技术选型也一样。你选一个框架、一个架构、一个技术栈，本质上是在买入一个期权。而大部分团队在做这个决策的时候，只看了"执行价格"——也就是今天的采用成本，完全忽略了到期时间和隐含波动率。

执行价格：你以为的成本只是首付

选React还是Vue？选微服务还是单体？选自研还是开源？这些决策的讨论，90%都聚焦在"今天迁移要花多少人力"上。

这就是只看执行价格。

我见过一个团队花了三个月从Vue迁到React，理由是"React生态更丰富"。三个月后确实迁完了，但接下来的一年里，团队不断在解决React生态的碎片化问题——路由、状态管理、样式方案，每一个都要做一个子决策。而当初评估迁移成本的时候，这些子决策根本没算进去。

就像买房只算了首付，没算物业费、维修基金和房产税。

很多从前端转 Node.js 的开发者，对这门运行时的理解停留在"写 JavaScript，能跑服务"这个层面。开发环境跑得好好的，上了生产环境，问题一个接一个冒出来，而且每一个都反直觉。

这不是水平问题，是 Node.js 的运行时设计给了你一种安全感——一种在开发环境完全验证不了、只有在流量压上来的那一刻才会破碎的安全感。

我自己在做 BFF 层的这些年，踩过太多这种坑。最深的感触是：Node.js 不会替你兜底，它只是让你以为它会。

事件循环不是安全网

Node.js 的文档里有一句很关键的话：事件循环在单个线程中运行。但很多人对这句话的理解是——"异步代码就不会阻塞"。

这是最大的幻觉。

`async/await` 只是语法糖，它让异步代码看起来像同步代码，但它不会把同步操作变成异步的。当你在一个请求处理函数里做了这些事情，整个事件循环都会停住：

- `JSON.parse` 一个 50MB 的请求体
- 用正则表达式匹配一个精心构造的字符串（回溯攻击）
- 在同步循环里做密集计算，比如加密、排序大数据集
- 调用了某个底层 C++ 扩展的同步接口

每个项目复盘的时候，技术负责人都会提一个问题：为什么又延期了？

然后大家开始列原因：需求变更、技术方案调整、第三方接口不稳定、测试环境问题……很少有人提"沟通"。

因为沟通好像不属于正经的工作。你写了一千行代码，那是产出；你开了三小时会，那是浪费时间。但实际情况是，你开的那三小时会，可能比写一千行代码对项目的影响更大——不管是正面还是负面。

沟通不是耽误开发，沟通本身就是开发

很多工程师有一种根深蒂固的观念：写代码才是正事，沟通是不得不做的打断。所以他们会尽量减少沟通——需求文档能不读就不读，能用文字说清楚的绝不开会，能自己决定的绝不找人讨论。

这种做法在个人项目里没问题。一个人写代码，沟通成本为零。但团队项目不一样。

一个五人团队，如果每个人对需求的理解偏差10%，最终集成出来的东西可能偏差50%。这不是数学平均，这是偏差的累积——前端理解的交互逻辑和后端理解的数据结构不一样，测试理解的验收标准和产品理解的验收标准不一样，等大家把代码合到一起才发现问题，修复的成本是开发阶段的十倍。

技术债务这个比喻太深入人心了，以至于所有旧代码都被贴上了"债"的标签。重构计划里排满了"还债"任务，架构升级的理由是"降低技术债务"，新人入职第一件事是听老人抱怨欠了多少债。

但仔细想想，你管它叫债，它就真的欠了什么吗？

债务这个比喻哪里不对

债务意味着你有偿还义务。你借了钱，必须还。到期不还，利息越滚越多，最终破产。

代码不是这样的。

一段跑得好好的代码，即使写法丑陋、架构混乱、没有测试覆盖，只要它在生产环境稳定运行，就没有人强迫你"还债"。业务的每一个需求都可能让你动这段代码，但你可以选择不动它——包一层，绕过去，新功能走新路径。

真正的问题不是"不还债会怎样"，而是"你还了债能得到什么"。

大部分技术债务偿还计划高估了收益。重构一个模块，你的预期收益是什么？代码更整洁了，开发者体验更好了，将来改起来更方便了。但这些收益几乎无法量化。你很难说服老板说："我花两个礼拜重构这个模块，将来的需求开发速度会提升百分之多少。"

而你需要放弃的成本是实实在在的：两个礼拜的业务产出，可能还有引入 bug 的风险。

这不是债务，这是投资。投资就得算回报，而不是用"还债"的道德感来绑架决策。

每个技术团队都会经历这样一个时刻：现有工具不太顺手，自己做一个吧。

理由总是充分得无法反驳——市面上的组件库不支持我们这种交互模式，开源的表单引擎处理不了我们的动态字段逻辑，第三方的配置中心满足不了我们的合规要求。每一条拿出来都是刚需，每一条都指向同一个结论：我们得自己造。

没人会在这个阶段反对。因为反对意味着你要证明"现有的东西够用"，而提出造轮子的人已经把"不够用"的场景摆上了桌面。你没办法反驳一个正在发生的痛点。

于是轮子开始转。第一周，大家很兴奋。第三周，初版出来了，确实比之前好用。第二个月，几个业务接入了。半年后，团队里有一半人的KPI跟这个轮子挂钩。一年后，最初写轮子的人提了离职。

这就是造轮子的故事。但今天我不想聊"该不该造"——这个问题已经被讨论过太多次，而且答案永远是"看情况"。我想聊的是一个更少人关注、却更致命的问题：造轮子最大的代价不是花时间开发，而是你再也走不掉。

开发成本只是首付

大部分人评估"要不要自己造"的时候，脑子里算的是开发成本。两个人做两个月，能搞定，成本就是四个人月。和采购方案比一比，好像更划算。这个算术本身没错，但它只算了首付。

真正的问题是后面几十年的月供。

每个前端团队最终都会走上同一条路：建组件库，搞设计系统，画设计规范文档。

然后看着它慢慢死去。

不是夸张。我见过太多团队花大力气搭了一套设计系统，上线时热热闹闹，半年后只剩一个人在维护，一年后连那个人也转岗了。业务线该自己封装的还是自己封装，该重复的还是重复，设计系统变成了一座精美的鬼城。

这个现象太普遍了，普遍到已经不值得用"执行力不够"来解释。问题不在人，在设计系统这个事情本身的逻辑里。

建设者的幻觉

设计系统的出发点通常很理想：统一视觉规范，提高开发效率，减少重复劳动。听起来无懈可击。

但这个逻辑有一个隐含前提——业务足够稳定，需求足够规范，变化足够可控。

现实呢？

金融产品恨不得每周换一轮视觉，大促活动页面跟日常页面完全是两套设计语言，某个业务线因为合规要求必须用特殊样式，另一个业务线因为老板拍板要用新风格。你精心设计的 Button 组件有十二个 variant，但业务要的是第十三个。

设计系统的建设者往往是架构团队或基础设施团队。他们离业务远，有时间做抽象。但离业务远恰恰是问题所在——你抽象出来的东西，天然跟不上业务的节奏。

2018年前后，Serverless在国内技术圈火了一阵。各大云厂商轮番布道，"按需付费"、"零运维"、"自动扩缩容"——每个口号都精准戳中了团队的痛点。我当时也投入了不少精力研究，毕竟谁不想不用管服务器？

几年过去了，当初那些All in Serverless的团队，相当一部分已经在往回走。不是Serverless不好，而是很多人慢慢意识到：当初以为消灭的复杂度，其实只是搬了个家。

那些承诺里没写的小字

Serverless的核心承诺有三条，每一条都有对应的现实版本。

"不用管服务器"——开发者只需写业务逻辑，基础设施平台托管。这对前端团队尤其有吸引力，写完函数丢上去就能跑，不用折腾部署和运维。但现实是，你很快会发现自己需要关注函数的内存配置、超时时间、并发限制、冷启动策略、VPC配置、IAM权限……这些不叫"服务器运维"，但本质上还是在管基础设施，只是换了个仪表盘。

"按需付费"——代码不运行就不收钱，空转成本消失。但下一句没人告诉你的是：按需付费的反面是成本不可预测。一个函数死循环触发重试，一个爬虫突然疯爬你的API，一个配置错误导致无限调用——这些异常场景下的账单，会让你深切怀念固定成本的日子。

先说一个我在做推荐系统 AB 实验架构时观察到的现象。

某个业务团队跑了一个月的实验，结论是新的推荐策略效果显著，CTR 提升了 12%，上线。三个月后回头看，整体转化率没变——用户只是提前点了，没有多买。没人复盘这件事，因为所有人都已经在那个"12% CTR 提升"的实验报告上签了字。

这不是个例。在金融产品场景里，我见过太多 AB 实验的结果被当作结论使用，而实验本身的设计、指标选择、对照组偏差，几乎没人认真审视。大家需要的不是真相，是一个可以写进周报的数字。

数据驱动这个词已经被用烂了

每家公司都说自己是数据驱动的。但如果你仔细看他们做决策的过程，会发现一个很典型的模式：先有结论，再做实验。

产品经理已经有了想法，设计已经出了方案，开发已经排了迭代——实验只是最后的"验证"。注意，不是"验证假设"，是"验证决策"。这两者有本质区别。验证假设的时候你真心想知道答案，验证决策的时候你只想要一个通过。

这种心态不是某个人有问题，是整个系统的激励结构决定的。一个做了三个月的项目，谁愿意在最后一步承认实验结果不支持上线？于是你会看到各种"实验结果不显著但趋势向好"、"主要指标未达显著但次要指标表现优异"的结论。翻译成人话就是：实验没通过，但我们还是要上。

每个技术团队都经历过这种场景：选型评审会上，几个方案摆出来，有人做性能对比，有人秀Demo效果，有人贴GitHub Star数。讨论半天，拍板一个，然后散会。团队满怀期待地开始新项目，三个月后开始骂娘。

这事儿我见过太多次了。选型时看到的都是优点，上线后暴露的全是成本。而且这些成本绝大多数在选型评审时根本没人提——不是不想提，是没人知道该提什么。

技术选型最大的陷阱不是选错了框架，而是你以为自己只选了框架。

你看到的是Demo，你看不到的是深渊

选型评审时，我们评估什么？功能列表、性能基准、社区活跃度、文档完整度。这些都是对的，也是不够的。

它们属于"可见成本"——你能在两小时的评审会上完成对比的东西。但框架的真正成本，从来不在这张表上。

每次团队讨论 Git 工作流，场面都很热烈。有人搬出 Git Flow 的严谨分支模型，有人推荐 Trunk-Based Development 的极简主义，还有人觉得 GitHub Flow 够用就行。辩论往往持续一个下午，最后投票选一个，README 里写上规范，全员执行。

然后三个月后你会发现：分支还是乱成一锅粥，release 分支上堆了二十个 cherry-pick，hotfix 从 master 拉出来合不回去，有人偷偷开了 feature branch 三周没合，还有人在 master 上直接 commit——"就改了一行，没必要开分支"。

工作流选错了？不，工作流没选错。是大部分团队在选工作流的时候，选的是自己向往的工作方式，而不是自己实际具备的发布能力。

Git Flow：为发布窗口而生的妥协

Vincent Driessen 在 2010 年提出 Git Flow 的时候，他的假设非常明确：你的软件有固定的发布周期。develop 分支积累功能，release 分支冻结测试，master 分支只放生产代码，hotfix 从 master 拉出紧急修复。每一步都有清晰的语义。

每个技术团队都有这个痛点：核心开发离职了，系统没人敢动；某个服务只有一个人能改；新人来了三个月还在问"这个接口谁负责"。然后管理层拍板——写文档！搞知识库！做Wiki！

半年后，知识库变成了数字垃圾场。文档没人读，读了也过时，过时了更没人更新。循环往复。

我的判断可能比较尖锐：文档是知识孤岛的安慰剂，不是解药。真要打破知识孤岛，得从架构设计和组织设计入手，让知识天然不容易集中到某个单点上去。

知识孤岛是怎么长出来的

先得搞清楚，知识孤岛不是"文档没写好"的产物。它是系统架构和组织结构的影子。

当一个微服务只有一个人从设计到上线全程参与，那这个人就是这个服务的知识孤岛。不是因为他不愿意分享——他可能写了很详细的README，但你让另一个人接手，还是要花两周才能上手。因为README里写的是"怎么做"，而脑子里装的是"为什么这么做"以及"哪里会踩坑"。

过去一年，我接触了不少AI和机器人方向的创业团队。有做具身智能的，有做服务机器人的，有做工业检测的，也有做消费级陪伴机器人的。聊完之后一个很强烈的感受：大量的创业者——尤其是技术背景出身的——正在用软件的思维做硬件的生意，用SaaS的逻辑评估一个物理世界的项目。

这个错位，比大多数人以为的要严重得多。

Demo到产品的距离，在硬件世界里是光年

软件创业的核心叙事是MVP——最小可行产品。两周上线一个版本，收集用户反馈，快速迭代。这套方法论在过去十年被验证了无数次，几乎成了互联网创业的圣经。

但这个叙事在机器人领域完全不成立。

一个做餐厅配送机器人的团队跟我说，他们的软件系统三个月就搭好了，SLAM算法调了两个月效果不错，避障也过得去。但整机跑起来之后，发现轮子打滑导致里程计漂移，激光雷达在不同光照条件下噪点差异巨大，电池在冬天衰减了30%导致续航不达标，餐厅地面的油渍让轮子寿命从设计的一半都不到。每一个都是"小问题"，但要解决任何其中一个，都需要改模具、换供应商、重新做可靠性测试——一个循环下来三个月起步。

软件出bug可以热修复，硬件出问题只能召回。软件改一行代码的成本是几分钟，硬件改一个结构件的成本是几万块起，加上开模周期至少四周。这不是量变，这是质变。