二开做完系统变慢?先查插件这 5 个地方,附排查顺序

很多企业上完 ERP 用了一两年，会遇到一个共同的现象：功能越来越多，系统却越来越慢。

点保存要等、打开单据要转圈、月底单据一多直接卡住。IT 部门第一反应是服务器该升级了，网络该扩容了。升级完发现，该慢还是慢。

原因往往不在硬件，而在这些年陆续加的二次开发插件上。功能是加对了，但写法把性能吃掉了。

下面这 5 个地方，是二开插件拖慢系统最常见的原因，也是排查时该看的顺序。

第一个：循环里访问数据库

一张带一百行明细的销售订单，插件在循环里逐行去查物料信息、查库存、查价格。一百行就是一百次查询，每次都有网络往返和解析开销。

单子十行的时候感觉不出来，等业务量上来、单据行数变多，慢得非常明显。

排查方法：看插件代码里有没有在 foreach 里调用查询。有，就改成先把所有 ID 收集起来，一次批量查回来，放字典里比对。

第二个：事件挂得太宽

BOS 插件可以挂在加载后、赋值后、字段变化、按钮点击等事件上。有的插件为了省事，把同一套逻辑挂在了四五个事件上，甚至挂在单据类型的基类上。

结果是：用户改一个数量，整单所有逻辑重跑一遍；打开一张不相干的单据，插件也跟着跑。

排查方法：看这个插件到底该在哪个时点执行，只留必要的那一个事件。查询类逻辑放加载后，计算类逻辑放字段变化，写库类逻辑放保存前。

第三个：事务里做远程调用

这是最容易被忽略、后果也最严重的一个。

保存单据时，系统会开一个数据库事务。有的插件在这个事务中间去请求外部接口、推送第三方系统。对方接口慢三秒，你的事务就多持有三秒的行锁；对方超时，整单回滚，业务员白填一遍。

排查方法：插件里凡是 HTTP 请求、消息推送，都从保存事务里挪出去，改成保存成功之后异步处理，失败了进重试队列。

第四个：同一件事查了三遍

前端页面校验一次、后端服务校验一次、插件里再校验一次。三次查的是同一张表、同一个条件。

看起来每次都不慢，叠加起来就是用户感知到的"卡"。

排查方法：校验分层，一层只做一次；重复的查询结果在上下文里缓存住，同一事务内复用。

第五个：全表扫描和大结果集

查询条件写得不完整，或者拿明细表字段去过滤，没走到索引，数据库只能全表扫。数据量小的时候没感觉，几十万行之后就是秒级等待。

排查方法：看执行计划，确认走的是索引；查询必须带过滤条件；列表类查询一定要分页。

排查顺序建议

先看现象落在哪个操作上：是打开慢、保存慢，还是查询慢。

打开慢，优先查加载事件里的逻辑和插件注册范围； 保存慢，优先查循环查库和事务里的远程调用； 查询慢，优先看 SQL 条件和索引。

上线前怎么把关

一是需求评审阶段先问一句：这个需求，标准配置能不能解决。能用参数、单据转换、工作流解决的，不写代码。

二是开发阶段定规矩：批量查询代替逐行查、事件只在必要处挂、外部调用移出事务。

三是上线前压测：不是造十条数据跑通就算完，要按真实最大明细行数和并发人数跑一遍，记录单笔耗时。

四是留后手：插件要能开关，出问题能快速停用；关键逻辑要有日志，慢在哪一步查得到。

二开本身没错，企业确实有标准产品覆盖不到的场景。但二开的价值不在写得多，在于改动少、跑得快、出问题能回退。

系统慢不一定是硬件不行。先看看这些插件，往往比加服务器更有效。