1. 项目概述：当Update语句“失灵”时
如果你用过MyBatis-Plus（后面简称MP），大概率对它的updateById或者update方法爱不释手。把实体对象一扔，框架自动帮你生成SQL，省去了手写<update>标签的繁琐。但不知道你有没有遇到过这样的场景：你只想更新用户表的“最后登录时间”字段，于是你new了一个User对象，只设置了id和lastLoginTime，然后满怀信心地调用了updateById。结果一查数据库，不仅时间没变，连用户的用户名、邮箱这些字段都莫名其妙被清空成了NULL！或者反过来，你明明给实体对象的某个字段赋了值，希望它更新到数据库，执行后却发现这个字段在SQL里压根没出现，更新了个寂寞。
这不是灵异事件，也不是MP的Bug，而是它的**字段更新策略（FieldStrategy）**在“作祟”。这个策略是MP设计中的一个核心特性，初衷是为了避免误操作，但在不了解其机制的情况下，它就成了一个隐蔽的“坑”。今天我们就来彻底拆解这个“MyBatis-Plus Update更新策略问题”。这不仅仅是解决一个API怎么用的问题，更是理解MP如何帮你做决策，以及当你需要完全掌控SQL时，如何从框架手中“夺回”控制权。无论你是刚接触MP的新手，还是已经踩过几次坑的老鸟，搞清楚这里的门道，都能让你在数据持久层操作上更加得心应手，避免生产环境出现数据被意外覆盖或丢失的严重问题。
2. 核心策略解析：FieldStrategy的三副面孔
要解决问题，首先得知道问题从哪来。MP的字段更新策略，主要通过@TableField注解的insertStrategy和updateStrategy属性来控制，它们都是FieldStrategy枚举的实例。这个枚举定义了当MP构建INSERT或UPDATE语句时，如何处理实体类中某个字段的值。理解这几个策略，是掌握MP更新行为的关键。
2.1 策略枚举详解：NOT_NULL, IGNORED, NEVER
FieldStrategy主要有四种策略，但最常用、也最容易引发问题的就是前三种：
2.1.1 NOT_NULL (默认策略)这是MP全局配置的默认策略，也是绝大多数“坑”的来源。它的逻辑是：只有当字段值不为null时，才会被包含进SQL语句中。
- 在UPDATE中的行为：如果你调用
updateById(user)，MP会检查user对象里每个字段。假设username字段是null，那么生成的SQL就不会包含username=？这一部分。这听起来很合理，对吧？但问题在于，你new出来的User对象，除了你主动set的字段，其他字段默认就是null！MP认为你不想更新这些null的字段，于是跳过了它们。但数据库期望的是，如果你不提供某个字段，它应该保持原值。然而，在某些误配置或特定写法下，框架或数据库驱动可能会产生非预期的行为（虽然MP自身生成的SQL是正常的，但开发者容易误解）。更关键的是，如果你的意图是“将某个字段更新为null”，这个策略会直接阻止你，因为值为null，它就被忽略了。
2.1.2 IGNORED (无视策略)这是最“霸道”也最直接的模式。无论字段值是什么（即使是null），都会被拼接到SQL语句中。
- 在UPDATE中的行为：继续上面的例子，如果
username字段被标记为IGNORED，那么updateById(user)生成的SQL一定会包含username=？。如果你set了值，就用你的值；如果你没set，它就是null，那么SQL就会变成username=null，从而将数据库中的该字段真正更新为NULL。这个策略把控制权完全交给了开发者，你需要对自己传入的对象值负责。
2.1.3 NEVER (永不策略)这个策略比较特殊。无论字段值是什么，都不会被包含在INSERT或UPDATE语句中。
- 在UPDATE中的行为：一个标记为
NEVER的字段，比如create_time（创建时间），在更新操作中会被完全忽略。即使你错误地给它赋了值，MP也不会让它出现在SET子句里，这非常适合用于保护那些不应该被更新的字段。
2.1.4 其他策略FieldStrategy还有DEFAULT（跟随全局配置）等，但理解上述三个就足以应对99%的场景。
为了更直观，我们用一个表格来对比：
| 策略枚举 | 在UPDATE中的行为 | 适用场景 | 风险提示 |
|---|---|---|---|
| NOT_NULL (默认) | 字段值不为null时，才加入SET子句。 | 通用场景，防止意外用null覆盖字段。 | 最容易踩坑。无法实现“更新为null”的需求；新手容易误以为没set的字段会被保留，实则可能因对象状态引发问题。 |
| IGNORED | 无论字段值是否为null，都加入SET子句。 | 1. 需要将字段显式更新为null。 2. 希望完全自主控制每个字段的更新行为。 | 风险最高。如果对象字段未正确赋值，极易导致数据被意外覆盖为null。 |
| NEVER | 永远不加入UPDATE的SET子句。 | 保护字段，如create_time,version（乐观锁字段通常有单独处理）等。 | 较为安全，明确禁止更新。 |
2.2 策略生效的优先级：注解、全局与默认
知道了策略是什么，还要知道谁说了算。MP中字段策略的生效遵循一个明确的优先级：
第一优先级：@TableField注解在实体类的字段上直接使用@TableField(updateStrategy = FieldStrategy.IGNORED)，那么这个字段的更新策略就以注解为准。这是最精细、最推荐的控制方式。
第二优先级：全局配置在MP的配置类中，可以通过MybatisPlusProperties或GlobalConfig.DbConfig设置全局的默认策略。
@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); // 添加分页插件等 return interceptor; } // 通过配置类设置全局策略 (Spring Boot 方式) @Bean public ConfigurationCustomizer configurationCustomizer() { return configuration -> { GlobalConfig globalConfig = new GlobalConfig(); GlobalConfig.DbConfig dbConfig = new GlobalConfig.DbConfig(); // 设置全局更新策略为 IGNORED（慎用！） // dbConfig.setUpdateStrategy(FieldStrategy.IGNORED); // 设置全局插入策略 // dbConfig.setInsertStrategy(FieldStrategy.NOT_NULL); globalConfig.setDbConfig(dbConfig); configuration.setGlobalConfig(globalConfig); }; } }注意：将全局策略设置为
IGNORED是非常危险的行为！它会让所有未显式声明@TableField策略的字段都采用IGNORED，极大增加误更新数据为null的风险。除非你非常清楚整个项目的实体类状况，否则不建议这么做。
第三优先级：MP默认值如果既没有字段注解，也没有全局配置，那么就会采用MP内置的默认值，也就是FieldStrategy.NOT_NULL。
理解这个优先级至关重要。当你发现某个字段的更新行为不符合预期时，就应该按照这个顺序去排查：先看字段注解，再看全局配置，最后想到默认行为。
3. 典型问题场景与深度剖析
理论说完了，我们来看实战中具体会撞上哪些墙。下面这几个场景，我相信不少人都遇到过。
3.1 场景一：部分更新失效，字段未按预期更新
这是最经典的“坑”。假设有一个商品Product实体，你只想更新它的库存stock。
Product product = new Product(); product.setId(1L); product.setStock(100); productMapper.updateById(product);你的期望SQL是：UPDATE product SET stock = 100 WHERE id = 1但实际可能（在默认NOT_NULL策略下，且其他字段为null时）生成的SQL从语法上是正确的。然而，开发者的困惑点在于：他们担心MP会生成一个包含所有字段的SET，并将未设置的字段设为null。实际上，在默认NOT_NULL策略下，MP不会将值为null的字段加入SET。真正的风险点不在这里，而在下面两种认知误区或延伸场景：
误用QueryWrapper进行部分更新：有些人会这样写：
Product product = new Product(); product.setPrice(new BigDecimal("99.9")); productMapper.update(product, new QueryWrapper<Product>().eq("id", 1));如果
price字段的更新策略是NOT_NULL，而product对象只有price有值，其他为null，那么生成的SQL确实是只更新price。这里的“坑”在于，如果QueryWrapper没有匹配到任何记录，更新操作会影响0行，但程序不会报错，容易让人误以为更新成功了。“动态”更新认知偏差：开发者常常有一种错觉，认为MP的
updateById是“动态”的，只会更新变化了的字段。这其实不准确。MP的“动态”是指根据字段值的是否为null来决定是否参与SQL构建，而不是根据字段值是否“发生了变化”。如果你从数据库查出一个对象，修改了某个字段，但其他字段保持原值（非null），那么更新时，所有非null字段都会被加入SET。这可能导致并发下的乐观锁问题，或者更新了不需要更新的字段。
解决方案与实操心得：
- 明确意图：如果确定是部分更新，最清晰的做法是使用
UpdateWrapper。
这种方式完全绕开了实体对象和字段策略，直接指定SET内容，意图明确，SQL可控。productMapper.update(null, new UpdateWrapper<Product>() .set("stock", 100) .eq("id", 1) ); - 善用
@TableField注解：对于确实需要通过实体对象进行部分更新的字段，可以将其策略设置为IGNORED，但务必谨慎，并清楚知道传入的对象状态。 - 查询后更新：先根据id查询出完整的实体对象，修改需要改的字段，再更新。这能保证其他字段有正确的值，不会被误判为null。但要注意数据一致性和性能开销。
3.2 场景二：想设null却无效，策略的“保护”成了“阻碍”
业务上常有将某个字段置空的需求。比如，用户解绑微信，需要将wx_openid字段设为null。
User user = new User(); user.setId(1L); user.setWxOpenid(null); // 意图设为null userMapper.updateById(user);在默认的NOT_NULL策略下，无论你set成null还是不set（默认就是null），MP检查到wxOpenid为null，都会直接忽略这个字段。生成的SQL根本没有wx_openid这个条件，更新自然无效。
解决方案与实操心得：
- 局部方案（推荐）：给这个特定的字段加上
@TableField(updateStrategy = FieldStrategy.IGNORED)注解。这样，当你显式set为null时，它就能被更新到数据库。public class User { @TableField(updateStrategy = FieldStrategy.IGNORED) private String wxOpenid; } - 全局方案（不推荐）：如之前所述，修改全局配置为
IGNORED，风险极高。 - 使用UpdateWrapper：这是最安全、最推荐的方式，完全不受实体类策略影响。
userMapper.update(null, new UpdateWrapper<User>() .set("wx_openid", null) .eq("id", 1) );
3.3 场景三：误用IGNORED导致数据意外覆盖
这是另一个极端。有的开发者为了“省事”，或者遇到了NOT_NULL的坑，一怒之下将全局策略或某个关键字段改成了IGNORED。
public class Order { @TableField(updateStrategy = FieldStrategy.IGNORED) // 危险操作！ private String address; // ... 其他字段 }然后在某次业务更新中：
Order order = new Order(); order.setId(1001L); order.setStatus(2); // 只想更新状态 orderMapper.updateById(order);由于address字段是IGNORED，且order对象中address是null，生成的SQL就会包含address = null。于是，订单1001的收货地址就被清空了！这是一个非常严重的生产事故。
解决方案与实操心得：
- 原则：
IGNORED策略是一把锋利的双刃剑，必须慎用。绝对不要为了“方便”而将其作为全局默认策略。 - 精确注解：如果某个字段确实需要接受null值更新，只给这个字段加
IGNORED注解，而不是一片区域。 - 防御性编程：在Service层，构建用于更新的实体对象时，要非常清楚每个字段的状态。对于部分更新，优先考虑
UpdateWrapper。或者，采用“查询-修改-保存”的全量更新模式，虽然有一定性能损耗，但数据安全性更高。 - 代码审查：将
@TableField(updateStrategy = FieldStrategy.IGNORED)的使用纳入代码审查重点，确保其必要性。
4. 最佳实践与精准配置方案
理解了问题和场景，我们来系统性地看看如何安全、高效地使用MP的更新功能。
4.1 策略选择指南：何时用何策
这没有一个绝对标准，但可以遵循以下原则：
- 绝大多数普通字段：保持默认的
NOT_NULL即可。它能防止你在大多数情况下意外地用null覆盖数据库已有值。 - 允许被置空的可选字段：例如
备注(remark)、外键ID(foreign_id)等，可以使用@TableField(updateStrategy = FieldStrategy.IGNORED)。这样你既能更新为具体值，也能在业务需要时将其更新为null。 - 永远不应该被更新的字段：如
创建时间(create_time)，使用@TableField(updateStrategy = FieldStrategy.NEVER)。这是最安全的保护锁。 - 有特殊逻辑的字段：比如
乐观锁版本号(version)，MP有内置的乐观锁插件处理，通常不需要单独设置更新策略。又比如逻辑删除标志(deleted)，通常由删除操作管理，更新时也不应触碰。
4.2 推荐配置模式：注解为主，Wrapper为辅
我个人的经验是，在实体类设计阶段就做好规划，通过@TableField注解明确每个字段在更新时的“性格”。
@Data @TableName("sys_user") public class User { @TableId(type = IdType.AUTO) private Long id; private String username; // 默认 NOT_NULL， 更新时必须提供 private String email; // 默认 NOT_NULL @TableField(updateStrategy = FieldStrategy.IGNORED) private String nickname; // 昵称允许置空 @TableField(updateStrategy = FieldStrategy.NEVER) private LocalDateTime createTime; // 创建时间永不更新 @Version private Integer version; // 乐观锁，由插件处理 // ... 其他getter/setter }而在业务代码的Service层，根据不同的更新场景，选择最合适的工具：
- 全量更新（先查后改）：适用于需要确保数据一致性的复杂对象更新。
public void updateUser(UserDTO userDTO) { User user = userMapper.selectById(userDTO.getId()); // 使用BeanUtils或MapStruct等工具，将DTO的非空属性拷贝到user实体 BeanUtils.copyProperties(userDTO, user, "id", "createTime"); // 忽略不能拷贝的字段 userMapper.updateById(user); // 此时user是一个全字段都有值的对象 } - 精确部分更新（首选）：绝大多数场景下的最佳选择。
public void updateUserEmail(Long userId, String newEmail) { userMapper.update(null, new UpdateWrapper<User>() .set("email", newEmail) .eq("id", userId) ); } - 动态部分更新（基于实体）：在明确字段策略且对象状态可控时使用。
public void unbindWechat(Long userId) { User user = new User(); user.setId(userId); user.setWxOpenid(null); // 依赖该字段的 @TableField(updateStrategy = IGNORED) userMapper.updateById(user); }
4.3 全局配置的思考：保持克制
除非你在开发一个非常明确、所有实体行为都高度一致的小型项目，否则我强烈建议不要轻易修改全局的updateStrategy。默认的NOT_NULL是一个相对安全的设定。如果确实有大量字段需要IGNORED，那更应该反思实体设计是否合理，而不是通过全局配置来掩盖问题。
全局配置更适合用来设置一些通用的、无风险的规则，比如：
db-config.id-type: assign_id（设置主键ID生成策略）db-config.table-underline: true（开启下划线映射）db-config.logic-delete-field: deleted（配置逻辑删除字段名）
5. 高级技巧与深度排查指南
掌握了基础，我们再看一些进阶玩法和遇到复杂问题时的排查思路。
5.1 使用Lambda表达式与条件构造器进行类型安全更新
UpdateWrapper的set方法需要传入字符串形式的列名，容易写错。MP提供了Lambda表达式方式，在编译期就能检查类型安全。
public void updateUserStatus(Long userId, Integer status) { userMapper.update(null, Wrappers.<User>lambdaUpdate() .set(User::getStatus, status) // 编译期检查，避免拼写错误 .set(User::getUpdateTime, LocalDateTime.now()) // 可以链式调用多个set .eq(User::getId, userId) ); }这种方式结合了UpdateWrapper的精确控制和Lambda的类型安全，是当前MP中最优雅的更新方式之一。
5.2 排查字段更新行为的完整流程
当你发现更新不对时，不要慌，按这个步骤来：
开启SQL日志：这是第一步，也是最重要的一步。在
application.yml中配置：mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl # 控制台打印完整SQL执行你的更新方法，查看控制台输出的最终SQL语句。一看SQL，问题就清楚了一半。
检查实体类字段注解：对照输出的SQL，看哪个字段没出现或者不该出现。然后去实体类里检查这个字段的
@TableField注解，确认其updateStrategy。检查全局配置：如果字段没有注解，去项目的配置类（如
MybatisPlusConfig）里检查是否设置了全局策略。检查传入的实体对象状态：在更新代码前打上断点，或者打印日志，确认你构建的实体对象里，目标字段的值是否如你所想。特别是当你是从其他地方（如RPC参数、前端DTO）转换而来时，要确保转换过程没有丢失值或误置null。
考虑MP插件的影响：检查是否配置了
乐观锁插件、自动填充插件（MetaObjectHandler）。这些插件可能会在更新时自动修改某些字段的值（如version、update_time），干扰你的判断。
5.3 与“动态取消租户隔离”等热词的关联思考
最近社区里“mybatis-plus 动态取消租户隔离”是个热点。这其实和更新策略在思想上有相通之处：都是对MP默认行为的精细化控制。租户插件默认会给所有SQL加上租户ID条件，但在某些全局管理场景下需要临时取消。这就像字段更新策略默认是NOT_NULL，但在特定字段上你需要IGNORED或NEVER。
这种“默认行为+局部覆盖”的设计模式，是MP这类增强框架的核心哲学。理解这一点，不仅能解决更新策略问题，也能举一反三，更好地理解和使用MP的其他特性，比如分页插件、性能分析插件等。它们的本质都是在提供便利的同时，通过配置给你留出掌控细节的后门。
6. 总结与个人体会
绕了一大圈，其实MyBatis-Plus的Update更新策略问题，核心就是理解框架的默认行为，并学会在需要时精确地覆盖它。NOT_NULL是MP给你的一把安全锁，防止你误操作。但当你需要更灵活的控制时，@TableField注解和UpdateWrapper就是你手中的钥匙。
我个人在实际项目中的体会是：
- 约定大于配置，但配置必须清晰：尽量使用MP的默认行为（
NOT_NULL），这能形成团队共识。任何对默认行为的偏离（使用IGNORED或NEVER），都必须通过清晰的@TableField注解来标明，并且要在设计评审中说明理由。 - UpdateWrapper是好朋友：对于业务Service层的方法，我越来越倾向于使用
UpdateWrapper（尤其是Lambda方式）来进行更新。它意图明确，不受实体对象复杂状态的影响，SQL一目了然，非常适合在团队协作中减少误解。 - 全量更新并非洪水猛兽：在事务边界内，对于核心的、状态复杂的领域对象，先
selectById再修改最后updateById的全量更新模式，在数据一致性上的收益往往大于其带来的额外一次查询开销。特别是在使用乐观锁时，这种模式几乎是标配。 - 日志是你的眼睛：遇到任何MP相关的诡异问题，第一时间打开完整的SQL日志。框架生成的SQL不会说谎，它能直接告诉你MP是如何理解你的意图的。
最后，记住一点：任何框架的便利性都伴随着一定的“黑盒”复杂度。MyBatis-Plus通过更新策略这样的设计，试图在智能和可控之间找到平衡。作为开发者，我们的任务不是抱怨它的“坑”，而是深入理解其设计原理，从而驾驭它，让它真正成为提升开发效率的利器，而不是生产事故的源头。花点时间搞清楚FieldStrategy，你在使用MP进行数据操作时，会更有底气，代码也会更加健壮可靠。
