取余异常需在操作前记录原始入参、TraceId和操作意图；禁用只记结果、拼接字符串、丢堆栈、循环高频打印等无效日志；配合断言校验业务约束。

线上取余结果异常，本质是某个计算环节的输入值超出预期范围，或运算逻辑被隐式改变。直接看结果没用，关键得知道“谁传了什么数进来、在哪个环节做的取余”。加日志不是为了证明它错了，而是为了还原现场。

只打一行，必须含三个要素

在取余操作前紧挨着加一条日志，格式统一、不拼接、不脱敏关键数字：

• 原始入参全量记录：比如 a % b，就记 a={} 和 b={}，不能只记结果或省略其中一个
• 上下文标识带上 TraceId：用 MDC 或手动传入，确保这条日志能串进整条调用链，方便关联前后请求
• 明确标注操作意图：写成 "[取余校验] 计算 a % b, a={}, b={}"，而不是模糊的 "计算参数"

避开常见坑：这些写法等于没记

以下做法看似省事，实际会让日志失去定位价值：

• 只记结果："a % b = {}" —— 不知道输入是什么，无法复现
• 拼接字符串打堆栈：log.info("a=" + a + ", b=" + b + ", result=" + (a%b)) —— 若 a 或 b 为 null，直接 NPE，日志都打不出来
• 用 e.getMessage() 方式记异常：log.warn("取余失败: " + e.getMessage()) —— 丢掉堆栈和入参，只剩一句空话
• 在循环里高频打印：for (int i : list) { log.debug("i % 10 = {}", i % 10); } —— 一次请求打几百条，淹没真实线索

配合检查点，快速确认是否真异常

取余本身不会出错，但业务上常有隐含约束（比如 b > 0、a >= 0、b 是固定模数）。建议在日志后加轻量断言：

• if (b
• if (a

这类判断不替代日志，但能把“参数越界”类问题从“结果异常”提前归类为“输入非法”，大幅缩短排查路径。