取余异常需在操作前记录原始入参、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
这类判断不替代日志，但能把“参数越界”类问题从“结果异常”提前归类为“输入非法”，大幅缩短排查路径。
