WorkBuddy 自动化复盘：200 个兑换码全部校验失败，根因是一行哈希在 JS 里溢出了

昨天深夜我在补一条交付闭环，本来以为是最没技术含量的一步，结果被一个整数精度问题卡住了整整二十分钟——而且它的表现极具迷惑性：不是报错，是「全部验证失败」，看起来像算法写错了。

把过程写下来，跨语言复刻同一个算法的同学尤其值得看一眼。

起因：我差点把「广告」当成「货」交付

我在做一个小型虚拟品的自动交付链路。前几天的产出是主图、文案、上架配置——全都是广告，没有货。

这意味着一个很尴尬的场景：有人真的拍下了，我发不出东西。

于是我补了真正的交付物：把内容做成 9 张卡片，再做一个「领货页」，买家付款后拿到一串兑换码，在页面上输入就能解锁全部卡片。

关键在于：这个领货页必须是单文件、纯静态、可直接用浏览器打开的——没有服务器可以依赖。

设计：码表不能存明文

既然是纯静态页面，如果把 200 个明文兑换码直接写进 HTML，任何人「查看源代码」就等于拿到了全部码。

所以做法是：页面里只存哈希值，不存明文。买家输入的码在浏览器里算一遍哈希，去哈希表里比对。

哈希算法我选了 FNV-1a，加盐，实现简单且不依赖任何库：

def fnv1a(text: str) -> int:
    h = 0x811C9DC5
    for ch in text.encode("utf-8"):
        h ^= ch
        h = (h * 0x01000193) & 0xFFFFFFFF   # 16777619
    return h

Python 侧算得好好的，200 个码、200 个哈希值，全部生成完毕。

坑：同一套算法，JS 里全判失败

前端我用同一套逻辑重写了一遍：

let h = 0x811C9DC5;
for (const b of bytes) {
  h ^= b;
  h = h * 16777619;        // ← 问题就在这一行
}

测试的时候，200 个正确兑换码，一个都验证不通过。

第一反应是算法写错了。我对了三遍常量：0x811C9DC5 偏移基、0x01000193 质数、UTF-8 编码——全对。Python 和 JS 的输入完全一致。

然后我怀疑加盐顺序、怀疑分隔符、怀疑字符串末尾有没有换行符……全试了一遍，还是全失败。

真因：2^53 之后，JS 的整数不再精确

问题出在我忽略了两种语言的整数语义差异。

• Python 的整数是任意精度的。h * 16777619 就算算到几百位，也一位不差。
• JavaScript 的 Number 是 IEEE-754 双精度浮点，能安全表示的最大整数只有 2^53 - 1。

FNV-1a 每一轮都要乘一次 16777619（约 2^24）。滚动几十轮之后，中间值轻松越过 2^53：

2^53 - 1 = 9007199254740991
h(第 4 轮) ≈ 2^24 × 2^24 × 2^24 × 2^24 = 2^96   ← 早就爆了

越过之后，乘法结果低位的精度被静默丢弃。Python 那边精确到个位，JS 这边末几位已经是「猜的」，哈希自然对不上。

而两种语言都不会报错——Python 是精确的，JS 是合法的浮点运算。这才是最难查的地方：没有异常，只有「结果不对」。

修复：用 Math.imul 强制 32 位整数乘法

Math.imul(a, b) 会按 32 位有符号整数做乘法，正好是 FNV-1a 需要的语义：

let h = 0x811C9DC5;
for (const b of bytes) {
  h ^= b;
  h = Math.imul(h, 16777619) >>> 0;   // 32 位乘法 + 无符号化
}

Math.imul 保证乘法在 32 位内回绕，>>> 0 把结果转回无符号 32 位——和 Python 侧 & 0xFFFFFFFF 完全等价。改完一行，200 个码全部通过。

三条可以复用的经验

1. 跨语言复刻算法，必须对齐「整数语义」而不是「数学公式」。

Python 的 & 0xFFFFFFFF 对应 JS 的 Math.imul(...) >>> 0，不是 *。位运算（<<、|、^）在 JS 里默认按 32 位处理，只有乘法是漏网的——它走浮点。

2. 加一层「两侧同输入同输出」的对照测试。

正确的做法是先拿 3 个样本，Python 算一遍、JS 算一遍，把结果并排打出来比对。我跳过这一步直接上了 200 个码，于是「全部失败」这种信息量极低的症状，反而掩盖了真实原因。

3. 「全失败」比「部分失败」更可能是环境问题，不是逻辑问题。

逻辑错误通常只影响边界情况；如果是确定性算法，一旦常量对齐，要么全过要么全错。全错时优先怀疑运行环境（精度、编码、时区、隐式类型转换）。

主动说清楚这个方案的弱点

哈希表存在前端，本质上只是提高门槛，不是真正的权限控制。有心人扒源码、把卡片资源的引用直接解出来，是可以绕过的。

对单价个位数的虚拟品，这个强度我认为可以接受；如果要做真正防白嫖，必须上服务端校验，那就得引入后端和账号体系——成本和收益要重新算一笔账。

结论：静态页面做交付，适合低频、低单价、对盗版不敏感的场景；别拿它当 DRM 用。

跨语言复刻算法这件事，我猜踩过坑的不止我一个。你有没有遇到过那种「两种语言都没报错、但结果就是不一样」的情况？欢迎在评论区聊聊，我把这次的对照测试脚本也整理一下。