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

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

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

自由是设计的天敌

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

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

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

猜猜三年后哪个更健康？

几乎无一例外，第一类系统更健康。因为合规约束虽然让人痛苦，但它强制你在设计阶段就想清楚数据流、权限边界和异常场景。而第二类系统在享受了初期的高效之后，会被技术债和意外行为压垮——数据泄露、越权操作、状态不一致，这些问题不是"会不会发生"的问题，是"什么时候发生"的问题。

约束逼你回答不想回答的问题

合规要求的核心价值不在于它规定了什么，而在于它强迫你面对那些本来会绕过的问题。

举个例子，"敏感数据不能在前端明文展示"这条规则，看起来只是让你多写一个脱敏函数。但它真正逼你思考的是：什么是敏感数据？数据在哪个环节脱敏？脱敏后的展示和编辑怎么联动？如果用户需要修改脱敏字段，脱敏状态和编辑状态的切换怎么处理？

这些问题，没有合规要求的话，大部分团队会怎么处理？直接把后端返回的数据渲染出来，完事。因为"目前够用了"。

但"目前够用"就是技术债的起点。等哪天真的出了数据泄露，你不是补一个脱敏函数就完事的——你需要回过头梳理所有展示敏感数据的页面，而那时候你可能已经不记得哪些页面有、哪些没有了。

合规要求在你还没写代码的时候就逼你做这个梳理。它的价值不是规定结果，是规范过程。

最难的架构决策是"不做"

很多人觉得架构设计是决定"做什么"——用什么技术栈、选什么架构模式、怎么做数据流。但实际上，最难的架构决策是"不做"。

一个没有约束的系统会不断膨胀。新需求来了就加接口，新场景来了就加字段，新功能来了就加页面。没有任何力量阻止你说"不"。而合规天然就是一个说"不"的机制。

"这个数据不能传到前端"——意味着你必须在后端完成聚合，前端只拿展示需要的数据。这条约束直接决定了BFF层的数据编排方式。

"这个操作必须双人复核"——意味着你不能用简单的CRUD，必须引入工作流和状态机。这条约束直接决定了业务流程的架构模式。

"这个接口必须幂等"——意味着你不能用隐式状态传递，必须显式管理请求的生命周期。这条约束直接决定了接口设计规范。

你看，合规要求的每一条"不能"，都对应着一个架构决策。而如果没有人替你说"不能"，你大概率会选择最简单的方案——也就是将来最难维护的方案。

金融业务的"过度设计"其实是最优设计

有个常见的批评是：金融业务的前端架构"过度设计"了。一个表单要搞分层、要搞状态机、要搞权限矩阵、要搞审计埋点，明明一个useState就能搞定的事情非得搞这么复杂。

我对这个批评的回应是：这不是过度设计，这是对复杂度的正确分配。

一个没有合规约束的表单，复杂度确实低——开发的时候低。但出了问题之后呢？用户投诉数据算错了，你查不出是哪个环节改的；运营发现有人越权操作了，你不知道是从哪个入口进来的；监管问你要操作日志，你发现关键节点没留痕。

这些问题的修复成本，远高于一开始就设计的成本。而且修复的时候，你还不能破坏现有逻辑——于是你在原本"简单"的代码上打补丁，一层又一层。三年后这个"简单"的表单变成了一个没有人敢动的意大利面条。

相比之下，金融业务的表单一开始就分层设计：展示层负责渲染和脱敏，逻辑层负责状态机和校验，数据层负责接口调用和幂等。看起来复杂，但每一层都有清晰的职责和边界。出了问题，你知道去哪一层查。改需求，你知道改哪一层。

这种"过度设计"实际上是最优设计——它把复杂度分配到了正确的位置，而不是让它随机堆积。

约束的可迁移性

更有意思的是，合规逼出来的设计模式是可以迁移的。你在金融业务里学会的分层设计、数据流管理、权限矩阵、审计追踪，换到其他行业照样好用。因为这些模式解决的不是"合规问题"，而是"复杂度问题"——合规只是让复杂度提前暴露了而已。

反过来，没有合规约束下发展出的"灵活"设计模式——无状态管理的自由组件、无鉴权的开放接口、无日志的隐式操作——这些在低复杂度场景下确实够用，但一旦业务复杂度上升，就全变成了需要推倒重来的理由。

我现在的判断是这样的：如果你只做过没有合规约束的业务，你大概率会低估架构设计的重要性。不是因为你能力不行，是因为约束不够的时候，糟糕的设计不会立刻惩罚你。而合规约束的真正作用，就是让糟糕的设计尽早暴露。

不是所有约束都是好约束

说了这么多约束的好处，也得承认不是所有约束都是有价值的。

有些合规要求确实是形式主义：为了过审而加的空壳检查、为了填表而写的废纸文档、为了满足检查项而设计的无用中间层。这些约束不会产生好的设计，只会产生更多的代码。

区分有价值的约束和形式主义的约束，标准很简单：这条约束是否改变了数据流或者控制流？如果改变了，它大概率是有价值的——因为它迫使你重新思考信息的流转方式。如果只是增加了检查点但没有改变流本身，那它大概率是形式主义——它只是在你已有的设计之上贴膏药。

另一个判断标准：这条约束是否可测试？可测试的约束通常会引导出更好的设计——因为你必须有明确的预期行为才能写测试。不可测试的约束（比如"代码要有良好的可维护性"）则不会产生任何设计上的帮助，它只是增加了焦虑。

写在后面

如果让我给年轻时候的自己一个架构方面的建议，我会说：别逃避约束，去寻找约束。甚至在没有外部约束的时候，自己给自己加约束。

因为自由不是设计的朋友，它是设计的敌人。一切好的设计都是在约束下产生的——预算约束、时间约束、技术约束、合规约束，甚至审美约束。没有约束的设计不是设计，是堆砌。

金融业务教会我的最重要的一课，不是什么高深的架构模式，而是这个朴素的道理：限制越多，选择越少，反而越容易做出正确的选择。

这不是什么深刻的洞察，但我觉得很多工程师还没有真正理解它。