金蝶云社区里有个案例被反复提起：生产环境直接给单据加字段，引发锁表阻塞。这不是理论风险，是真实事故。
事故是怎么发生的
业务方临时提了一个需求，要在单据上增加一个标记字段。开发觉得简单，直接在生产的元数据里加了字段，没走变更流程、没在测试环境验证、没挑时间窗口。
结果加字段触发了表结构变更，大表上的 DDL 持有排他锁，等待的会话越积越多，整个单据模块的读写全部阻塞。前端表现为转圈，后端日志里全是锁等待超时。
根因不在技术，在流程
加字段这个动作本身没有技术难度。问题在于三件事同时缺失：
一，没有变更窗口。生产环境的表结构变更必须放在业务低峰，且要提前通知。
二，没有测试环境验证。字段加在测试库上跑一遍，能提前发现依赖这个表的视图、报表、插件会不会报错。
三，没有回滚预案。字段加上去了，出问题想撤，得再执行一次 DDL，而这时候系统已经在阻塞状态，撤的难度更大。
正确的做法
先在测试环境加字段，跑一遍完整的业务链路：单据录入、提交、审核、下推、报表查询。重点看自定义报表与插件，这两处最容易因为字段变化而崩。
确认无问题后，评估表的数据量。大表的 DDL 要单独排窗口，必要时用在线变更工具或者先在备库操作再切换。
执行时盯着数据库的锁等待视图，一旦出现长事务立刻中止。
给做二开的人一句提醒
金蝶的二开生态很成熟，社区里有大量反面案例，包括 view.close() 导致的 OOM、DataSet 循环里做长时间处理、PostgreSQL 关联更新的语法陷阱。这些案例的共同点都是“本地跑得好，生产上出事”。
本地数据量小、并发低、没人同时操作，这三个条件在生产环境全部不成立。任何涉及表结构、批处理、循环内 IO 的改动，都必须按生产标准验证。
流程比技术重要
这次事故之后，那家企业的做法是把生产环境的 DDL 权限收归 DBA，开发只能提变更单。听起来低效，但比再来一次全模块阻塞便宜得多。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。
