关键在于识别“零值误写”，即int的0、boolean的false等默认值未经校验直接拼入SQL或传给JPA实体，导致库存被意外覆盖为0；需通过日志验证、DTO类型改造、动态更新配置及防御性校验来排查与防范。
排查这类问题，关键在于识别“零值误写”——即把 int 的 0、boolean 的 false、double 的 0.0 等语言默认值，未经校验就直接拼入 SQL 或传给 JPA 实体，导致库存被意外覆盖为 0。
确认是否发生了零值覆盖
先验证现象是否属实：
- 查数据库变更日志（如 MySQL binlog）或应用层审计日志，看某次更新语句的 SET 子句中是否出现
stock = 0这类显式赋值，且该操作并非业务主动设为零（例如清仓） - 对比更新前后的实体对象：在调用
repository.save()或执行UPDATE前打日志，输出待更新字段的原始值。若发现item.getStock()打印为 0，但前端/业务逻辑本应未传该字段，就基本锁定是空参或默认值透传 - 检查 DTO 接收层：Spring MVC 默认会将缺失字段初始化为基本类型默认值（不是
null），比如 JSON 中没传"stock"字段，但 DTO 里定义的是private int stock;→ 反序列化后值就是 0
重点排查 DTO 与实体映射环节
这是最常出问题的位置：
- 避免使用基本类型接收可选字段：把
int stock改成Integer stock，这样前端不传时值为null，后续可明确判断“未提供” vs “明确设为 0” - 禁用 Jackson 对基本类型的静默初始化：在配置中添加
spring.jackson.deserialization.fail-on-null-for-primitives=false不够，更稳妥的是全局注册自定义反序列izer，或统一用@JsonInclude(JsonInclude.Include.NON_NULL)控制序列化行为 - DTO 转 Entity 时做显式判空：不要用
BeanUtils.copyProperties()直接拷贝，而是手写转换逻辑，对每个可能为零的字段加条件判断：if (dto.getStock() != null) entity.setStock(dto.getStock());
检查 ORM 更新策略是否放大风险
JPA/Hibernate 的全量更新模式容易把默认值刷进去：
- 确认是否用了
@DynamicUpdate(false)（默认值），导致每次save()都生成包含所有字段的 UPDATE 语句。应启用动态更新：@Entity @DynamicUpdate，让 Hibernate 只更新实际修改过的字段 - 避免直接 new 实体再 set 全字段：比如
Item item = new Item(); item.setId(123); item.setStock(0); repo.save(item);—— 这种写法必然覆盖 stock 为 0。应先查出原实体，再选择性修改字段 - MyBatis 用户注意
<update>标签内是否写了无条件的stock = #{stock}。应改用<if test="stock != null">stock = #{stock}</if>
增加防御性校验和监控
从机制上堵住漏洞：
- 在 Service 层更新前加断言：
if (updateDto.getStock() != null && updateDto.getStock() <br>同时对 0 值做业务语义判断：是允许清零？还是表示“忽略此字段”？ - 数据库加 CHECK 约束：
ALTER TABLE item ADD CONSTRAINT chk_stock_non_negative CHECK (stock >= 0);
虽不能防 0，但能拦住负数等明显异常值，且约束失败会抛异常，暴露问题 - 对库存字段变更做埋点监控：当检测到 stock 从非零突变为 0，且非运营手动操作，立即告警
