阿努比斯（Anubis）v1.28.0-pre1.0.20260906214259-7564aa1d8a85 版本在 2026 年 9 月 6 日完成了一次重要的功能更新，团队花费了一整年的时间，终于将 WebAssembly 正式集成并发布到了这个项目当中。
正文
你给的快照只包含 Anubis 的防护信息页，不是《It took a year to ship WebAssembly in Anubis》的博客正文。页面内容只有 Anubis 版权声明、托管信息和运行版本号（v1.28.0-pre1.0.20260906214259-7564aa1d8a85），没有可简写的技术文章正文。请提供原始文章正文或可正常访问的页面，我再按原文顺序作中文简写并保留配图。
评论
这场讨论整体克制而友善，但立场明显分成两拨：多数人把 PoW 理解为抬高滥用成本的经济学工具，少数人则认为 Anubis 的前提根本站不住脚。评论里还夹杂着绕过工具、兼容性细节和数学换算的零星考据。
反爬本质是算经济账，不是消灭抓取
- 多位评论者认为，bot 治理不需要让抓取在技术上不可能，只要把边际成本抬高到滥用流量无利可图，机器人流量自然会变少（较多人）。 > 反爬虫其实是经济问题：不必让抓取不可能，只要让它贵到滥用不再划算。（@miraline）
- 也有同方向的人带点遗憾：这类 PoW 烧掉的算力没有任何回报，不像加密货币挖矿至少还能换来可以卖掉的 token。
抓取方既不缺算力也不缺内存，Anubis 的前提恐怕是反的
- 少数人直言，就 argon2 那点计算量，作者设想的“以后让 AI 顺手写个 CUDA 求解器这条路会被堵死”根本不现实；大规模抓取方恰恰拥有远超消费设备的算力。（少数人）
- 内存维度也被单独拎出来质疑：真正的大规模抓取方是那些把内存占满的 AI 公司，他们怎么会缺内存？ > 我没太想明白 Anubis 中长期该怎么运转。它是在假设抓取方——也就是那些抢着囤满内存的 AI 公司——会缺内存吗？（@raincole）
希望 PoW 能提前算好，做成浏览器可花的积分
- 有读者希望 PoW 支持“离线打工”：空闲时算好换取积分或令牌，真正干活时浏览器直接花掉，而不是每次访问都被迫现场等一下。（少数人） > 如果 PoW 能提前完成就好了，工作时就不用卡住等待。最好做成某种积分/令牌，让浏览器到时候直接花。（@0x696C6961）
与其上 Anubis，不如根级 robots.txt；它也是“不欢迎机器人”的识别信号
- 一位跑私有爬虫的读者说自己会老实遵守 robots.txt，因此不理解这类站点为什么不在根级放一个。他甚至打算加一个“Anubis 检测器”：凡是部署了它的站点一律拉黑，理由很简单——对方显然不欢迎机器人。（少数人）
欣赏作者在向后兼容上花的功夫
- 有人佩服 Xe 肯为了 Chrome 66 这类老环境投入大量时间做兼容，认为这种“费劲又不讨好”的工作值得敬佩；也有人只留下一句“谢谢你努力让 Web 别变得那么糟”。（较多人） > 敬佩 Xe 花这么多时间在向后兼容上，尤其是 Chrome 66 那段。在我看来，要保证兼容，最好用变化节奏更慢的工具链，比如 ClojureScript。（@kccqzy）
有价值的补充
- 浏览器端已经出现两代“加速破解”扩展：先是用 WASM 去跑 anubis solver，后来又有人用 WebGPU 把速度再提一个数量级。防线刚落地，攻防就已经开始升级。
- 有用户建议提供兼容性试玩页，免得人忙正事时才发现环境不兼容；并提醒 wasm2js 回退路径没有进度条，很多人会以为“0 hashes/s”是卡死而关掉页面。
- 若要在 Rust 里重编标准库，要找的编译开关叫 build-std；编译多线程 wasm 目标时同样会用到它。
- 有读者对“难度 +1 在最坏情况下相当于难 1024 倍”的换算表示困惑：从 bit 升到 nibble 不应该是 16 倍吗？
- 有人在回复里想贴图来演示兼容性问题，结果图片本身直接 404——他随即表示这张坏图完美证明了作者的观点。
- 一位正在自研 WASM 1.0 JIT 的读者印证：C++ 标准库想独立编译成小体积 WASM 很不容易，恐怕只能投靠整套 Emscripten；他还建议把最新的两个 Firefox ESR 版本纳入测试，因为 Linux 发行版常预装它们。
- 还有人专门摘出文中那句关于开源维护者待遇的讽刺，说它精准呼应了 HN 社区反复讨论过的 OSS 维护者被粗暴对待的现象。