Anubis 耗时一年集成 WebAssembly
It took a year to ship WebAssembly in Anubis
在 Anubis 项目中集成 WebAssembly 并非一蹴而就，我们足足花了一年时间才将其成功上线。这段旅程充满了技术挑战与架构重构，从最初的性能瓶颈到最终的稳定交付，每一步都凝聚了团队的坚持与智慧。WebAssembly 的引入不仅提升了 Anubis 的执行效率，也为未来扩展功能打开了新的大门。这是一次关于耐心、技术深度与工程落地的真实记录。
我们花了一整年时间，才让 WebAssembly 在 Anubis 中真正跑起来。
HN 评论区
187- vintagedave
根据我的经验，恰好处于这种特定情境下的人，往往也是那些对挡了他们路的开源项目作者表现出极大善恶意差的人。
太妙了。HN 上过去就有过关于开源维护者待遇的讨论，这句话真是讽刺得恰到好处。我很欣赏这种对待问题的语气和态度。
- doctor_radium
我手边所有的 Firefox 副本都配置为禁用 WebAssembly……因为我不怎么做 WebAssembly 设计的那些事，比如在线游戏、音视频编辑、模拟器等等 [1]，而且我不喜欢不知情的情况下有东西在后台运行。
所以这将会很有趣。
我（小声地）恳请楼主：就像许多网站对 JavaScript 做的那样，请在 WebAssembly 被禁用时，在代码中添加一条“此验证码需要 WebAssembly 才能继续”的提示。顺便一提，对于那些根本不提供 WebAssembly 引擎的小型平台/浏览器也是如此。
- andai
有点跑题，但我看到的受 Anubis 保护的所有页面都只是静态 HTML。但机器人流量不是只在动态页面上有害吗？
- dspillett
> 这也意味着“嘿 Claude，帮我写个 CUDA Anubis 求解器”这条路基本上要彻底死掉了。
我假设之前的挑战在 WASM 不可用的情况下仍然可用（除非我们只是默认只要 JS 可用 WASM 就可用？），或者作为后备方案。TFA 明确提到了“智能”电视，我相信外面有很多运行着旧到根本不知道 WASM 为何物的浏览器的电视。老实说，这些对我来说不是优先事项，但显然对这个项目来说很重要，毕竟它们在文中被特别提及（好吧，是电视整体，不特指老旧电视）。
如果是这样，有什么能阻止爬虫直接强制使用后备的 POW 选项，而不是尝试运行新的内存密集型算法呢？
- kccqzy
向 Xe 致敬，他在向后兼容性上花了这么多时间，特别是关于针对 Chrome 66 的那个小细节。
我有一台 2014 年的 Mac 运行着 Yosemite，偶尔用来测试我自己的前端代码的向后兼容性（纯属娱乐！）。但在我看来，确保兼容性的最佳方式是使用符合当时时代的工具链，或者变化节奏较慢的工具链，比如 ClojureScript。
- Aachen
有没有什么地方可以让我测试我的浏览器是否兼容？现在查出来总比等到我想干活时，发现一百万个网站都部署了它再查要容易。
在 https://wasm-feature-detect.surma.technology 上显示我缺少所有特性中的 3 个，但我不确定 Anubis 是否需要这些特性才能避免把我踢回纯 JS 方案。
这似乎会很糟糕，因为：
> 随此流程发布的 WebAssembly 性能极其出色。这可能意味着你需要调整难度 [向上，以避免支持 wasm 的机器人轻易破解，我猜是这个意思]
再加上：
> wasm2js 流程目前没有更新进度条的方法 [所以你完全不知道还剩多少时间]
（这也不是我第一次因为页面卡在 0 哈希/秒而放弃加载了）
- Georgelemental
你可以使用 Rust 的 `wasm32v1-none` 目标来获取没有额外目标特性的基础 WASM。（但这会将你限制在 `#[no_std]` 环境中。）https://doc.rust-lang.org/rustc/platform-support/wasm32v1-no...
- 0x696C6961
如果 POW 能提前完成就好了。这样我工作时就不会被卡住等待。某种类型的积分/代币，我的浏览器可以用来消费。