排查此类bug的核心是区分“0为合法业务值”与“0为默认值掩盖的空/错/未初始化状态”；需核查数据库not null default 0设置、java用integer而非int、前端/api/excel是否允许空、sql动态默认值语法、binlog审计定位写入源头，并通过校验熔断与数据质量脚本根治。
排查这类 Bug 的核心，是识别“0 是真业务值”还是“被默认值掩盖的空/错/未初始化状态”。它不报错、不崩溃，但库存数字悄悄失真，尤其在多模块协作或字段类型混用时极易埋雷。
确认字段是否真的允许业务值为 0
先厘清业务语义：库存数量为 0，代表“已售罄”，这是合法有效状态；但“入库单的实收数量为 0”“采购单的到货重量为 0”，大概率是录入遗漏或逻辑跳过，而非真实业务结果。重点检查：
- 数据库表结构中该字段是否有 NOT NULL DEFAULT 0 —— 若有，需反向验证：所有写入路径是否都显式赋值？有没有漏掉分支（如异常处理、条件未覆盖）导致走默认值？
- 对应 Java 实体类字段是否为 int 而非 Integer —— 基本类型无法表达“未填写”，一旦未赋值就自动为 0，而包装类型可为 null，便于后续判空拦截。
- 前端表单、API 入参、Excel 导入模板中，该字段是否允许为空？若后端接收为 int，JSON 传 null 或缺失字段时，Jackson 默认会设为 0，而非报错或跳过。
追踪 0 值从哪条路径写入数据库
不是查“谁读了 0”，而是查“谁写了 0”。在关键更新语句（如 UPDATE stock SET quantity = ? WHERE id = ?）前后加日志，重点关注：
- SQL 执行前，打印绑定参数值 —— 确认传入的确实是 0，且不是日志格式化把 null 显示成 0；
- 调用栈上溯：是来自订单履约服务？还是供应商对账定时任务？或是某个兜底补偿逻辑？特别注意含 if-else 或 try-catch 的代码块，常见于“更新失败则设为 0”这类错误兜底；
- 检查 MyBatis 的
<update></update>SQL 中是否用了 #{xxx, default=0} 这类动态默认值语法，它会在参数为 null 时强行塞 0，掩盖原始空值。
用数据库变更审计快速定位问题批次
不依赖应用日志，直接从数据源头锁定异常写入时间点和范围：
- 启用 MySQL 的 binlog 或 PostgreSQL 的 logical replication log，用工具（如 Maxwell、Debezium）解析出所有
quantity字段被更新为 0 的记录，按时间排序，看是否集中在某次发布、某个定时任务周期或某类单据批量处理之后； - 执行快照比对：SELECT * FROM stock WHERE quantity = 0 AND updated_at > '2026-05-22 00:00:00'，再关联操作日志或单据主表，确认这批 0 值是否对应“无实际入库动作”的单据（如状态为草稿、取消、校验失败）；
- 对高频更新表添加触发器（临时），当
NEW.quantity = 0 AND OLD.quantity != 0时，将完整上下文（调用 IP、线程名、堆栈前几行）写入审计表，直击写入源头。
修复与防御措施
改代码只是止痛，建机制才能根治：
- 将库存类字段在数据库中设为 NOT NULL，但去掉 DEFAULT 0；应用层统一用 Integer 接收，强制所有写入路径做
Objects.nonNull()校验，null 值抛业务异常，不静默转 0； - 在 MyBatis 的
@Update方法入参中，用 @Param("quantity") Integer quantity 显式声明，配合<if test="quantity != null">quantity = #{quantity}</if>，避免 null 被误设为 0； - 在库存核心服务中增加“0 值写入熔断”：对非初始化场景的 quantity=0 更新，记录告警并人工复核，连续超阈值自动暂停该接口；
- 定期跑数据质量脚本：扫描所有 quantity=0 的记录，检查其关联单据状态、创建时间、操作人，生成“可疑零库存清单”供运营复核。
