做企业级低代码平台插件开发的朋友大概都有过这种体验：元数据里明明配好了插件类路径，表单打开也没报错，可一到提交、审核、反写这些关键节点，自定义逻辑就像掉进了黑洞，前台不报错、后台不打日志，只能靠一遍遍改代码加打印语句来猜。我最早接触bos-servicehelper这个工程工具类，就是被这类“插件静默失效”的问题逼出来的。它属于平台 BOS 侧服务插件支撑工程里的辅助类集合，干的活儿很朴素——把“插件怎么被找到、怎么被实例化、事件参数怎么传、异常怎么落日志”这些脏活累活收拢到一处，让业务插件只需要关心自己的业务规则。说白了，它是插件运行链路和业务代码之间的一层薄胶水，薄到很多人写了半年插件都没正眼看过它，但一旦出问题，排查的起点几乎总是它。
这篇内容适合三类人看：刚上手该平台、能照着模板写插件但说不清执行顺序的新人；被“配置生效但逻辑不跑”折磨过、想搞明白背后机制的中级开发者；以及要给团队做插件开发规范、需要统一入口和统一日志的技术负责人。我会把插件解析顺序、实例化与缓存、事件参数传递、异常包装这几块拆开讲，配上可以直接抄的代码和参数表，也会把我在实际项目里踩过的坑摊开讲——包括那次因为类加载器不一致导致插件连续三天“幽灵失效”的完整排查过程。文中涉及的类名、方法名做了简化处理，思路和顺序是通用的，换成你们团队自己的封装也能对应上。
1. 这个工具类到底在解决什么问题
1.1 先说清楚插件是怎么被“叫起来”的
想理解 bos-servicehelper 的价值，得先在脑子里跑一遍插件被调用的完整链路。在该平台的 BOS 建模体系里，业务对象（Bill/BaseData）的元数据会记录一组插件配置，通常包含插件类全限定名、注册的操作事件（比如 save、submit、audit、delete）、以及可选的执行顺序和启用开关。用户在前端点下“保存”按钮，请求打到服务端，操作引擎会先做权限与参数校验，然后进入操作执行阶段，此时它需要把元数据里登记的插件按规则解析成实例，在正确的时间点回调对应方法。
这里面有个关键点常被忽略：服务端拿到的只是一串字符串形式的类名，它必须经过类加载、反射实例化、接口校验、事件匹配四道关，才能变成一个能响应beforeExecuteOperationTransaction或afterExecuteOperationTransaction的对象。每一道关都可能失败，而失败的表现形式又极其相似——业务逻辑没执行。bos-servicehelper 在整个链路里的位置，就是把这四道关的判断逻辑和结果缓存封装成可复用的静态方法，让操作引擎和业务侧校验代码用同一套规则去解释“这个插件到底能不能用”。
从分层角度看，它不属于业务层，也不完全是框架内核，更接近“框架提供给工程侧的一把标准尺子”。你用它量出来的结果，和引擎内部量出来的结果一致，这就避免了“我本地测试能跑，线上就是不触发”这类最消耗人心力的偏差。
1.2 工程里那堆重复代码，才是真正的痛点
在没有统一工具类的项目里，插件相关的样板代码会长成什么样？我见过最夸张的一个工程，有七个业务模块各自写了一套“根据类名找插件、判断接口类型、捕获异常记日志”的方法，实现细节还不一样：有的用Class.forName，有的用线程上下文类加载器，有的干脆把异常吞掉只留一行e.printStackTrace()。结果就是同一个插件在不同模块下表现不一致，出了问题没人敢改，因为不知道改了会影响到谁。
这些重复代码带来的隐性成本远超想象。第一是语义漂移：A 模块认为“插件不存在”返回 null，B 模块认为应该抛异常，调用方拿到 null 之后直接 NPE，报错栈指向业务代码，实际根因在插件配置。第二是日志缺失：散落各处的 try-catch 让异常信息在不同层被反复包装、反复丢弃，最后只剩一句“操作失败”。第三是规则不一致：插件顺序、启用开关、父子插件继承这些规则，如果每个模块各写一遍，迟早出现“同一个单据在两个入口行为不同”的诡异现象。
工具类的本质是把这些规则收敛成唯一实现。它带来的收益不是性能，而是确定性——所有人对“插件为什么没跑”的判断依据是同一份代码、同一套日志、同一个返回语义。这一点在多人协作的中大型项目里，价值远大于省下来的那几十行代码。
1.3 边界在哪里：它不该做的事
用工具类最容易犯的错是过度使用。我在评审代码时经常看到有人在插件里调用工具类去做业务查询、去做参数转换、甚至去发消息，这就跑偏了。bos-servicehelper 这类工程工具类的职责边界其实很清楚：只处理插件生命周期相关的元信息操作，包括类名解析、实例化、接口兼容性校验、事件方法匹配、执行顺序排序、异常包装与日志归集。凡是涉及业务数据读写的，一律不该进去。
举个具体的反例。有人在工具类里加了一个“根据单据编号查插件配置”的方法，看起来很贴心，实际上把元数据缓存和业务数据查询耦合在了一起，一旦业务表结构变动，这个工具类就得跟着改版本，所有依赖它的插件工程都要重新编译。更麻烦的是，这种耦合会让工具类的单元测试变得极其脆弱，你不得不为它准备一整套业务数据。
守住边界的判断标准很简单：这个方法如果换个业务对象还成立，那它属于工具类；如果只对某类单据有意义，那它属于业务代码。按这个尺子量，绝大多数“顺手加进去”的方法都应该被踢出去。
2. 核心设计思路拆解
2.1 为什么选静态工具类，而不是抽象基类
这是个被讨论过很多次的设计选择。抽象基类的方案是让所有服务插件继承一个BaseServicePlugin，把公共逻辑放在父类里。听起来更 OOP，但在这个场景下我不推荐，原因有三个。
第一是继承位被占用。平台的插件体系里，服务插件通常已经有强制父类（比如操作服务插件基类），Java 单继承的特性决定了你没法再插一层自己的基类进去。硬要插，就得让业务插件继承你的基类，你的基类再继承平台基类，等于给平台升级埋了一颗雷——平台一旦调整基类的抽象方法，整条继承链上的所有业务插件都得跟着改。
第二是使用场景不匹配。工具类的方法在很多地方要被调用，包括非插件的地方：元数据校验工具、部署前的配置检查脚本、批量修复历史数据的运维程序。这些调用方根本不继承任何插件基类，它们只需要“给我查一下这个类名对应的插件能不能实例化”。静态方法天然适配这种跨场景调用。
第三是测试成本。静态工具类的方法大多是纯函数式的输入输出，给定类名字符串返回解析结果，单元测试写起来非常轻。抽象基类则往往带着不可控的上下文依赖，测试时得 mock 一堆东西。
静态工具类也有代价，最典型的是状态管理。如果工具类里放了缓存，就必须考虑线程安全和失效策略，这点后面单独讲。我的做法是把可变状态压到最小：只缓存“类名到 Class 对象”这种幂等映射，不缓存实例，不缓存业务数据，缓存容器用并发安全的实现。
2.2 插件链的解析顺序，决定了行为的上限
同一个操作上挂多个插件时，执行顺序不是随便排的。工具类在这块的职责是提供统一的排序与匹配逻辑，把元数据里配置的顺序值、插件类型（表单插件/服务插件/操作插件）、以及父子继承关系三者揉成一个确定的序列。
我整理过一套实际项目里验证有效的排序规则，按优先级从高到低：
| 优先级 | 判定依据 | 说明 | 常见坑 |
|---|---|---|---|
| 1 | 显式配置的 order 值 | 元数据里手写的顺序号，最小者先执行 | 多人协作时顺序号重复，导致顺序不稳定 |
| 2 | 插件类型权重 | 操作插件先于表单插件参与服务端事务 | 误把校验逻辑放在表单插件里，事务已开启才发现 |
| 3 | 继承层级 | 父对象插件先于子对象插件 | 子对象覆盖父对象逻辑时未考虑父插件已生效 |
| 4 | 注册时间 | 同权重下按元数据加载顺序 | 热更新后顺序变化，引发偶发 bug |
这张表里最容易被忽略的是第 3 条。该平台支持业务对象继承，子对象会继承父对象的插件配置。很多人写子对象插件时以为自己在“覆盖”，实际上父插件照样执行，两个逻辑叠加导致数据被改两次。工具类在这里应该提供一个明确的方法，让调用方能够区分“当前生效的插件全集”和“仅本对象声明的插件”，两者的语义完全不同。
还有一个细节是事件方法的匹配。元数据里注册的是操作事件，插件里可能有多个同名重载方法或不同的参数类型。工具类需要按照一套确定的规则去挑选目标方法：先看参数类型是否与事件参数兼容，再看方法可见性，最后看是否有注解标记。这套规则如果不统一，就会出现“同样的插件在 A 环境触发、B 环境不触发”的玄学问题。我一般会把匹配过程打一行 debug 日志，输出候选方法列表和最终选中项，排查时直接看日志比读代码快得多。
2.3 缓存与类加载隔离，必须一起考虑
工具类里最值得做缓存的是“类名 → Class 对象”这个映射。反射的Class.forName在热路径上调用是有成本的，虽然单次只有微秒级，但一个批量操作里插件解析可能被调用几千次，累积起来不可忽视。加上缓存之后，解析开销基本可以忽略。
但缓存一上，问题就来了：缓存的是哪个类加载器加载的 Class。该平台支持插件热部署，也支持多租户隔离，不同租户的插件可能来自不同的类加载器，甚至同一个类名在不同加载器下是两个完全不同的 Class 对象。如果你用一个全局静态 Map 缓存，键只用类名字符串，那就会出现 A 租户的插件实例被 B 租户复用的情况，轻则行为异常，重则类型转换失败抛ClassCastException。
我的处理原则是：缓存键必须包含类加载器标识。常见做法是用ClassLoader实例本身参与哈希，或者用“类名 + 加载器标识字符串”拼成复合键。前者更准确，但要注意加载器对象的生命周期，避免长时间持有导致无法回收；后者实现简单，代价是需要一个稳定的标识来源。
并发方面，我推荐用分段思路而不是一把大锁。具体实现上，ConcurrentHashMap配合computeIfAbsent已经能覆盖绝大多数场景，注意computeIfAbsent的映射函数里不要做耗时操作，更不要在里面对同一个 map 做写操作，否则会出现死锁或者并发修改异常。这一点我在早期版本里踩过，映射函数里顺手做了一次“失败回退注册”，结果在高并发下卡死了线程池。
注意：缓存一定要有明确的失效入口。哪怕当前不做主动失效，也要预留一个清空方法并在运维脚本里挂上，否则线上出现类冲突时你只能重启。
3. 源码级细节：几个高频方法的实现要点
3.1 插件查找与实例化：别把反射写成陷阱
插件解析的入口通常是一个接收类名和期望接口类型的方法，返回实例或者返回一个包含状态信息的结果对象。我更倾向后者，因为在批量场景下需要区分“找不到类”“类存在但接口不匹配”“实例化失败”三种情况，直接抛异常会让调用方很难做降级处理。
核心实现要点有这么几条。第一，类名要做空值和空格校验，元数据是从配置文件或数据库里读出来的，前后带空格的情况真实存在，Class.forName(" com.foo.Bar ")会直接抛ClassNotFoundException，而报错信息里空格不可见，排查时极其抓狂。第二，优先使用业务侧的类加载器，而不是工具类自身的加载器，否则热部署进来的插件类根本找不到。第三，接口校验要用isAssignableFrom而不是相等比较，因为业务插件往往通过中间抽象类间接实现目标接口。
public static PluginResolveResult resolve(String className, Class<?> expectedType) { if (className == null || className.trim().isEmpty()) { return PluginResolveResult.fail("类名为空"); } String trimmed = className.trim(); ClassLoader loader = Thread.currentThread().getContextClassLoader(); if (loader == null) { loader = expectedType.getClassLoader(); } try { Class<?> clazz = loadClass(trimmed, loader); if (!expectedType.isAssignableFrom(clazz)) { return PluginResolveResult.fail("类型不匹配: " + clazz.getName()); } Object instance = clazz.getDeclaredConstructor().newInstance(); return PluginResolveResult.ok(instance); } catch (ClassNotFoundException e) { return PluginResolveResult.fail("类不存在: " + trimmed); } catch (NoSuchMethodException e) { return PluginResolveResult.fail("缺少无参构造: " + trimmed); } catch (Throwable e) { return PluginResolveResult.fail("实例化异常: " + e.getClass().getSimpleName()); } }这段代码里有个容易被忽略的细节：catch (Throwable e)而不是catch (Exception e)。插件类的静态初始化块如果抛了NoClassDefFoundError或者ExceptionInInitializerError，那都是 Error 级别，用 Exception 接不住，会直接往上冒泡打断整个操作。用 Throwable 兜住之后转成结构化的失败结果，上层可以决定是跳过这个插件继续执行，还是整体中止。当然，兜住之后必须打日志，而且日志里要带类名，否则又是一个静默失败。
3.2 事件参数与上下文传递：隐式依赖最伤人
插件方法被回调时，引擎会传一个事件参数对象，里面装着当前操作的类型、单据数据、操作结果、以及可能的扩展上下文。工具类在这块的职责不是构造参数，而是提供安全的读取入口——因为事件参数对象在不同平台版本里字段会有增删，业务插件直接链式调用args.getDataEntity().getBillId()这种写法，一旦某一层返回 null，就是空指针。
我的封装思路是给常用字段提供带默认值的读取方法，并且把“取不到”和“取到了但是空值”区分开。比如取单据主键，方法签名设计成返回一个 Optional 风格的包装，或者提供一个getBillIdOrDefault(args, "")。这样业务代码里就少了一层判空，可读性提升明显。
上下文传递还有一个坑是线程切换。平台在某些场景下会把插件调用放到异步线程或者批量执行的子线程里，而上下文对象往往是 ThreadLocal 存的。如果工具类里的读取方法没有考虑跨线程场景，在子线程里就会拿到空上下文，表现为“插件在单条操作时正常，批量操作时全部失效”。这个问题的排查难度极高，因为在主线程加断点永远命中正确路径。解决办法是在进入异步分支前显式地把上下文快照传下去，工具类提供一个“绑定上下文到当前线程”的方法，在子线程开头调用一次。
3.3 异常包装与日志落点：让报错栈能直接定位
异常处理是这个工具类里最容易做砸的部分。做砸的典型表现有两种：一种是全吞，catch 之后打一行 warn 就返回 null；另一种是全抛，把反射产生的InvocationTargetException原样扔给上层，报错栈里全是框架代码，业务开发看不出是哪一行出的问题。
合理的做法是分层包装。反射调用产生的异常要拆包，把InvocationTargetException.getTargetException()取出来，这才是业务代码真正抛出的那个异常，栈信息才指向你自己的插件类。包装后的异常要保留原始 cause，不要只new RuntimeException(msg)，否则栈断链，排查时等于从头再来。日志只在最终处理点打一次，中间层只负责带上上下文信息，比如“哪个插件、哪个事件、哪个单据”。
try { method.invoke(pluginInstance, args); } catch (InvocationTargetException e) { Throwable target = e.getTargetException(); String scene = String.format("插件=%s,事件=%s,单号=%s", pluginInstance.getClass().getSimpleName(), method.getName(), safeBillNo(args)); log.error("插件执行失败 {}", scene, target); throw new PluginInvokeException(scene, target); }这里safeBillNo单独抽出来是有原因的。取单号的逻辑本身可能因为上下文缺失而抛异常，如果写在日志的字符串拼接里，就会出现“为了打日志又引发一个新异常”的连环崩溃，最终日志里什么有效信息都没有。所有用于拼日志的取值动作，都必须包一层防护。
4. 实操：从零跑通一个服务插件
4.1 工程依赖与环境准备
先把工程骨架搭起来。典型的插件工程是一个独立的 Maven 模块，依赖平台提供的 BOS 相关 jar，打包产物是一个 jar 包，放到平台的插件目录或者通过元数据上传。构建配置里有几个参数值得专门确认，我把它们列成表，因为配错任何一个都会导致插件“编译通过但运行找不到”。
| 配置项 | 推荐值 | 为什么 | 踩坑记录 |
|---|---|---|---|
| 编译目标版本 | 与平台运行 JDK 一致 | 高版本字节码在低版本 JVM 上直接抛 UnsupportedClassVersionError | 本地用高版本 JDK 编译，部署后整批插件不生效 |
| 依赖作用域 | provided | 平台 jar 运行时由容器提供，打进包里会造成类重复 | 打成 compile 后出现两个同名类，行为取哪个不确定 |
| 打包插件 | 保持 JDK 默认 | 避免额外的类加载层改变类名解析 | 用了某些打包工具后类路径变形，反射找不到类 |
| 资源文件编码 | UTF-8 | 元数据中的中文描述乱码会导致匹配异常 | 描述字段乱码后按名称查找插件始终返回空 |
环境准备阶段还有一个容易被跳过的动作：在本地启动一个最小可运行的测试环境。很多人习惯改完代码直接丢到测试服上验证，一轮下来十几分钟，效率极低。我的做法是在本地写一个 main 方法或者单元测试，直接调用工具类的解析方法，把元数据里配置的类名硬编码进去，跑一遍看能不能实例化、能不能匹配到事件方法。这一步能在编码阶段拦下八成以上的低级错误，包括类名拼错、少写无参构造、接口实现错。
4.2 编写插件与注册元数据
写一个服务插件，骨架大概是这样：继承平台的操作服务插件基类，重写前置和后置方法，前置做数据校验和补全，后置做关联数据的反写。这里的关键是校验逻辑尽量前置，因为前置阶段事务还没提交，抛异常能干净回滚；后置阶段事务边界处理不当，容易出现“主单据回滚了、关联单据已经改了”的脏数据。
public class DemoAuditPlugin extends AbstractOperationServicePlugIn { @Override public void beforeExecuteOperationTransaction(BeforeOpEventArgs args) { List<Object> rows = args.getDataEntities(); for (Object row : rows) { String status = ServiceHelper.getString(row, "status"); if ("CLOSED".equals(status)) { throw new KDBizException("已关闭的单据不允许再次提交"); } } } @Override public void afterExecuteOperationTransaction(AfterOpEventArgs args) { ServiceHelper.logInfo("审核后处理开始, 单数={}", args.getDataEntities().size()); } }元数据注册这一步是整个流程里最容易出错的地方。在业务对象的插件配置界面里，需要填类全限定名、选择事件、设置顺序。有三个细节必须核对：类名是否带包路径、大小写是否完全一致、事件类型选的是“操作”还是“表单”。我遇到过最隐蔽的一次是类名里有个字母大小写写反了，在 Windows 开发的本地环境里因为文件系统不敏感居然跑通了，部署到 Linux 环境直接失效，排查了大半天。
提示：注册完成后不要急着点业务按钮，先在元数据的插件列表里点“校验”或者调用工具类的诊断方法，确认解析结果。诊断通过再走业务流程，能把问题定位范围缩小一半。
4.3 本地调试与线上验证的关键动作
调试插件有个朴素的技巧：在插件方法的第一行打一条带唯一标识的日志。这条日志的作用不是看业务数据，而是确认“方法到底有没有进来”。太多时候我们在方法内部加了一堆日志，结果一条都没打出来，说明根本没进方法，此时应该去看注册配置和解析链路，而不是继续在方法体里找 bug。
线上验证则要关注执行耗时。插件是在主事务链路里的，任何一个慢查询都会直接拉长用户等待时间。我的习惯是在工具类里提供一个轻量的计时包装，在 debug 日志级别下输出每个插件的执行耗时，超过阈值的单独打一条 warn。阈值怎么定？我一般按“单插件 200ms、单操作全插件累计 1s”作为警戒线，超过就去看是不是在插件里做了全表查询或者循环调用远程接口。
验证顺序也有讲究。先验证单条操作，再验证批量操作；先验证正常流程，再验证异常分支；先验证主单据，再验证关联单据。这个顺序能把“上下文丢失”“事务边界”“批量数据量”这三类问题分别隔离出来。跳过单条直接测批量，一旦出问题，你无法判断是逻辑错误还是并发问题。
5. 常见问题与排查实录
5.1 插件“注册了但不生效”的七种可能
这是被问得最多的问题。我按排查成本从低到高整理成一张速查表，遇到问题从上往下过一遍，基本能在十分钟内定位。
| 现象 | 最可能原因 | 快速验证方法 | 处理方式 |
|---|---|---|---|
| 完全没有日志输出 | 类名或包路径写错 | 工具类诊断方法返回“类不存在” | 复制编译产物的全限定名重新粘贴 |
| 单条正常、批量失效 | 上下文跨线程丢失 | 在插件首行打印当前线程名 | 异步分支前显式传上下文 |
| 部分用户失效 | 租户或组织隔离导致加载器不同 | 对比失效用户与正常用户的租户 | 缓存键加入加载器或租户标识 |
| 改代码后行为没变 | 旧版本类被缓存未刷新 | 查看加载的类来源路径 | 清理缓存并重新部署 |
| 前置方法不进、后置方法进 | 事件注册选错 | 检查元数据事件配置 | 补注册前置事件 |
| 抛异常但前台无提示 | 异常被中间层吞掉 | 搜索日志中的 warn 级别记录 | 改为包装后上抛 |
| 偶发失效、重启恢复 | 类加载器泄漏或缓存污染 | 观察失效频率与部署次数关系 | 加缓存上限与失效入口 |
表里第五行值得多说两句。平台的前置事件和后置事件在元数据里是分开注册的，有些版本的界面上默认只勾了后置，开发时没注意，结果校验逻辑写在前置方法里永远不执行。这类问题的特点是“代码看起来完全正确”，只能靠核对配置解决。我的做法是在插件类上加注释，明确写出“本插件注册了哪几个事件”，部署前对着注释核对一遍元数据。
5.2 类加载冲突：那次连续三天的幽灵失效
说个真实的排查过程。项目上线后，某个单据的审核插件在测试环境一切正常，生产环境稳定失效，日志干净得像什么都没发生。第一天怀疑是元数据没同步，对比了两边配置完全一致；第二天怀疑是部署包版本不对，重新打包部署，问题依旧；第三天决定在工具类的解析方法里加详细日志，把类加载器、类来源路径、实例化结果全打出来。
日志一出来问题就清楚了：生产环境里同一个类名被两个不同的类加载器加载，工具类拿到的是平台基础加载器加载的旧版本，而元数据指向的是插件包里的新版本。旧版本里那个方法是个空实现，所以什么日志都没有。根因是之前的某次热部署没有清理干净，旧类残留在缓存里，新类加载时因为缓存键只用了类名，直接被命中了旧条目。
修复方案分两步：短期是加一个运维接口，手动清空插件解析缓存后重新触发；长期是把缓存键改成“类名 + 加载器标识”，并且给缓存加上容量上限和过期时间。这件事之后我养成了一个习惯：任何涉及类加载的缓存，键里必须包含加载器维度，哪怕当前看起来只有一个加载器。
注意：热部署之后一定要验证旧类是否真的被卸载。可以写一个诊断方法输出当前缓存的键集合，部署前后各打印一次做对比，比猜靠谱得多。
5.3 性能问题：插件里绝对不能做的几件事
插件跑在主事务链路里，写错一行可能就是几百毫秒。我列几条红线，都是用生产事故换来的。
不要在全量循环里查数据库。处理一千行明细，每行查一次关联表，就是一千次数据库往返。正确做法是一次性把关联数据捞出来做成 Map，循环里只做内存查找。这个道理谁都懂，但写的时候顺手就是一个for里套query。
不要在插件里调用远程接口。远程调用有超时风险，而且不受本地事务控制。一旦超时，本地事务还在挂着，连接池很快被占满。确实需要通知外部系统的，改成事务提交后的异步消息。
不要在插件里做大对象的深拷贝。某些场景下的数据快照会拷贝整个实体树，字段上百个、嵌套好几层，单次拷贝几十毫秒，批量操作下直接雪崩。
不要在插件里做全表统计。有些校验逻辑需要判断“这个编码是否重复”，写法是查全表再遍历。数据量小的时候没感觉，数据量上来之后这条查询就是整个操作的瓶颈。换成带条件的精确查询，或者加唯一索引让数据库来做这件事。
6. 我踩过的坑和几条实在建议
工具类的日志设计比功能设计更重要。早期我写的日志格式是“插件执行失败: xxx”，没带类名、没带事件、没带单号，线上出问题时拿着这句日志什么也定位不了。后来统一成“类名 + 事件 + 业务主键 + 异常栈”四要素，排查效率提升非常明显。如果你们团队还没统一日志格式，建议先把这一条定下来，成本极低、收益极高。
第二个建议是给工具类配一个诊断入口。一个静态方法，输入类名和期望接口，输出解析状态、类来源路径、匹配到的事件方法列表。部署前跑一次、出问题时跑一次，能覆盖大半的低级故障。这个入口做成运维脚本或者管理页面上的一个按钮都行，关键是让它容易被调用，否则没人会用。
第三个建议是别在工具类里做业务判断。我见过有人在工具类里加“如果是某类单据就走特殊逻辑”，理由是“好多插件都要用”。这种设计短期省事，长期是灾难，因为特殊逻辑会越来越多，最后工具类变成了一个谁都不敢动的巨型 if-else。正确的做法是把这类逻辑下沉到业务侧的公共插件里，工具类只提供能力，不提供策略。
最后一个体会关于版本管理。工具类被所有插件工程依赖，它的任何一次不兼容修改都会引发连锁反应。我的做法是保持方法签名的向下兼容，新增能力用新方法，废弃方法标上注解但至少保留两个大版本。听起来保守，但比起一次升级导致几十个插件工程重新适配，这点保守完全值得。
