写爬虫的人都有过这种崩溃时刻：本地跑得好好的脚本，一上服务器就被Cloudflare拦住，Chrome版本对不上驱动，内存占用莫名其妙飙到几个G。有人在HN上甩了一段代码，说这些问题他全解决了——用Bun跑，三行代码启动，还能自动点掉Turnstile验证框。
这个叫Mochi.js的库，核心卖点是"bun-native"。不是简单的包装层，而是直接扎进Bun的运行时里。传统方案像Puppeteer或Playwright，本质是Node调Chrome DevTools协议，中间隔了一层翻译。Mochi.js的作者显然嫌这层翻译太慢，干脆用Bun的内置API重写了一遍浏览器控制逻辑。
代码示例里藏着几个有意思的设计。第一个是profile系统——"linux-chrome-stable"、"mac-m4-chrome-stable"、"win11-chrome-stable"，不是随便起的名字，是完整的环境指纹。UA、字体列表、Canvas指纹、WebGL渲染器，全部按真实设备配置。seed参数更关键，同一个seed永远生成同一套指纹，这意味着你可以给每个账号分配固定的"设备身份"，而不是每次启动都是一台新电脑。
第二个是challenges模块。示例里演示了Turnstile的autoClick，这是Cloudflare的人机验证。代码结构留了个onEscalation钩子，说明作者知道自动点击会被升级检测——可能是变体验证码，可能是行为分析触发的人工复核。这个设计比硬闯聪明，至少让你知道在哪一步露馅。
第三个是addInitScript的JIT-friendly注释。在页面任何脚本执行之前注入代码，用的是Proxy陷阱而不是简单的字符串替换。这意味着你可以拦截JavaScript对象的访问，而且不会被页面的代码轻易检测到。示例里给window挂了个__site_marker，后面还能removeInitScript——不是一锤子买卖，是可持续的会话控制。
技术选型上，作者押注Bun是有风险的。Bun的兼容性还没达到Node的生态规模，但反过来想，能用Bun的生产环境，用户本身就更激进、更容忍早期项目。这个筛选机制反而帮Mochi.js找到了第一批种子用户：那些已经被Puppeteer的内存泄漏折磨到想换语言的人。
浏览器自动化这个领域，过去十年的叙事是"模拟真人行为"，现在的风向变成"直接就是真人行为"。不是改User-Agent假装Chrome，是真的启动一个Chrome，但把指纹管理、会话隔离、验证对抗这些脏活封装好。Mochi.js的代码示例没有展示性能数据，但"bun-native"这个词本身就在暗示速度——毕竟Bun的启动速度和内存效率，是Benchmark里反复验证过的。
值得观察的是seed机制的设计哲学。传统爬虫用代理IP轮换身份，Mochi.js用seed轮换设备指纹。IP可以封，设备指纹的封禁成本更高——尤其是当这套指纹模拟得足够真的时候。这有点像早年Android模拟器对抗游戏反作弊的军备竞赛，只不过战场换到了浏览器。
项目还在早期，GitHub星数没公开，但HN的Show HN板块向来是技术风向的晴雨表。上一个在这里火起来的浏览器自动化工具是Playwright，再之前是Puppeteer。如果Mochi.js能稳住Bun的兼容性，把profile库做厚——现在只有三个预设，显然不够——它可能会切走一块对延迟极度敏感的市场。比如广告验证、价格监控、账号矩阵运营这些场景，启动速度差几秒就是真金白银。
当然，风险也明显。Bun本身的迭代速度、Chrome版本升级的追赶、反爬策略的升级，都是悬在头上的剑。代码示例里那个onEscalation回调，既是功能也是伏笔——作者知道这场猫鼠游戏不会停。
热门跟贴