python -c "print('&'.join(k+'='+v for k,v in sorted({'B':2,'a':1}.items())))"
// Java: new TreeMap<>(params) 输出后手动 lowerCase 再比
同一组四个参数，Java 侧拼出的签名能过，Python 侧 100% 返回 sign error，参数值完全一样。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。
追下去是这么回事：Python 的 sorted 按 Unicode 码位排，Java 的 TreeMap 走自然序，key 里同时有大写字母和下划线时顺序就分叉了。顺序一变，HMAC 的输入整串错位，结果必然不同。
这次卡住的地方就在「签名参数排序差异」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。监控和日志的时间要对上，时区不一致会多绕很大一圈。
临时改动用注释写上日期和原因，过两周自己都记不清为什么这么写。动手前把原文件复制一份带时间戳，出问题立刻换回去，比现场分析快得多。
处理上按这个顺序：把两边拼出的待签串打印出来 逐字符比对；统一转小写并按 ASCII 升序排 key；空值和 null 的处理写进同一份说明；改完用同一组参数在两边各跑一遍。
确认没问题再收工，两边打印的待签串完全一致 签名值相同 回调返回 success。