应拦截 statementhandler——它持有最终拼好的 sql，可在 prepare 阶段通过 metaobject 修改 boundsql.sql 并同步补全 parametermapping，确保 sql 重写与参数注入一致，且无需改动 xml。
MyBatis 插件该拦截 ParameterHandler 还是 Executor？
直接拦 ParameterHandler 是错的——它只负责把参数塞进 PreparedStatement，不碰 SQL 字符串本身。你想“给所有 SQL 自动加上更新人”，本质是改 SQL 文本（比如在 UPDATE 语句末尾追加 , update_by = ?），必须在 SQL 渲染完成、但还没执行前动手。真正该拦的是 StatementHandler，它持有最终拼好的 SQL 和参数映射。
怎么在 StatementHandler#prepare 阶段安全修改 SQL？
MyBatis 的 StatementHandler 默认实现是 RoutingStatementHandler，它内部委托给 PreparedStatementHandler。我们得在 prepare 方法返回前，拿到它的 boundSql.sql 并重写。关键点有三个：
- 用
MetaObject反射拿到boundSql，再取sql字段（它是只读 final，所以得用set强制覆盖） - 只对
UPDATE类型语句操作，用正则判断sql.trim().toUpperCase().startsWith("UPDATE") - 避免重复添加字段：检查原 SQL 是否已含
update_by（比如用Pattern.compile("(?i)update_by\s*=\s*\?")）
示例片段：
String sql = boundSql.getSql();<br>if (sql.trim().toUpperCase().startsWith("UPDATE") && !hasUpdateBy(sql)) {<br> sql = sql.replaceFirst("(?i);?$", ", update_by = ?");<br> metaObject.setValue("boundSql.sql", sql);<br>}
更新人参数怎么塞进 ParameterHandler 不丢？
SQL 改了，就得同步补一个参数，否则执行时报 Parameter index out of range。不能自己 new 个 ArrayList 替换 boundSql.parameterMappings——MyBatis 后续会校验类型。正确做法是：
- 从
boundSql.parameterMappings复制一份新列表 - 构造一个新的
ParameterMapping，指定 property 为"_updateBy"（注意下划线前缀，避免和业务参数冲突） - 把新 mapping 加到列表末尾
- 用
new BoundSql(...)重建boundSql，并用metaObject.setValue("boundSql", newBoundSql)替换
别忘了在插件的 intercept 里，把当前用户 ID 存进 MappedStatement 的 additionalParameters（或用 ThreadLocal 透传），否则 ParameterHandler 拿不到值。
为什么不能在 MyBatis-Plus 的 MetaObjectHandler 里做？
MetaObjectHandler 只管实体类字段自动填充（比如 updateTime），它完全不接触 SQL 字符串。你加的 update_by 如果只设在实体上，MyBatis-Plus 会按字段名找列，但前提是你的 XML 或注解 SQL 里已经显式写了 update_by = #{updateBy}。插件方案是无侵入的，连 XML 都不用动——这点最容易被忽略，很多人卡在“为什么填了实体但 SQL 没变”上。
