很多团队一提老 ERP 重构，第一句话就是“数据库太乱了，先全库重做”。这话不一定错，但在真实项目里，它经常把重构直接带进深水区。因为老 ERP 的问题很少只在一层：数据库结构会影响接口质量，接口边界不清又会放大权限漏洞，权限一旦失控，最后连关键状态都可能被人绕过流程直接改掉。
所以我现在更少问“哪层最底、哪层最技术”，而是先问另一件事：现在到底是哪一层在持续制造业务事故、返工和维护成本。顺序判断对了，重构才像止血；顺序判断错了，项目很容易做了很久，还没碰到真正最痛的地方。
- 多数情况下，应该先把接口边界收紧
如果系统还在跑，最现实的约束通常不是技术，而是业务不能停。这个时候一上来大改数据库，报表、同步脚本、外围系统、历史兼容逻辑都会一起被卷进去，影响范围非常难控。
我更常见的稳妥做法，是先把接口层收住。先定清楚哪些动作允许外部调用，哪些字段不能随便写，哪些状态流转必须走固定入口。这样做的价值，不是看起来更“高级”，而是能先把最乱的写操作关进笼子里。接口边界一旦清楚，很多隐藏问题反而会自己浮出来，比如哪些逻辑还散在脚本里，哪些状态其实一直被多个系统同时改，哪些字段早就不该继续对外暴露。
- 只有数据口径已经失真，数据库才应该被前置
当然，也不是所有项目都该先动接口。有些老 ERP 的数据库已经不是“难看”这么简单，而是核心对象本身就不成立了。比如同一张订单在不同表里状态打架，主键关系不稳定，库存、明细、审批记录之间对不上，这种情况下再包一层接口，很多时候只是把脏问题包装得更复杂。
但就算数据库必须前置，我也不建议直接喊“全库重构”。更实际的做法，通常是先围着一条主链路动刀，比如订单、明细、状态流转、库存占用这几块最容易传导错误的数据。先把这一小块地基打稳，再决定外围怎么迁。老 ERP 真正怕的不是改得不够彻底，而是还没交付就把改造面铺得过大。
- 权限不一定先单独大修，但必须从第一阶段就卡住
权限这层特别容易被低估。很多老系统表面上有角色设计，实际关键动作还是靠前端隐藏按钮，或者默认给管理员太多万能权限。最后系统流程看起来在，关键状态却还是谁都能碰。
所以权限不一定要最先做成一套完整的大工程，但它必须从第一阶段就变成硬约束。哪些角色能改关键状态，哪些字段必须审批后写入，哪些操作一定要留痕，这些规则要先卡进接口和数据改造里。否则前面刚把结构理顺，后面又会被越权操作重新打乱。
- 重构顺序应该围着业务风险走，不要围着技术洁癖走
老 ERP 重构最容易犯的错，是一开会就讨论“先把底层做漂亮”。但真实交付里，更重要的问题通常是：哪类写操作最失控，哪条主链路最容易出事故，哪类越权最常见，哪部分一改就会影响一线业务连续性。
如果这些问题还没回答清楚，就急着决定“数据库先做”还是“权限先做”，项目大概率会越做越重。重构不是一次技术翻新秀，它首先是一次风险重排。先把事故最多、返工最多、最难追责的那层收住，后面的结构优化才有意义。
如果你也在评估老 ERP 重构，我更建议先把失控的写操作、最脆弱的主链路和最常见的越权场景列出来，再决定数据库、接口、权限谁先动。原文链接：sphrag.com/zh/blog/leg…
