我想在浏览器里直接跑任何 Nix 包，trynix.dev 居然真的实现了

直接给结论：如果你需要一个无需安装、不用配置环境，且能随时通过 URL 访问特定版本 Linux 软件包的临时 Shell，用 trynix.dev 就对了。它利用 qemu-wasm 在浏览器里跑一个 x86_64 的虚拟机，只要是 Nix 过去 13 年里的包，通过 URL 参数传参就能秒开，完全不需要后端服务器支撑。

怎么在浏览器里加载特定版本的包

这个工具最强的地方在于 URL 地址化。你不需要在页面里找搜索框，直接在 URL 后面接 ?pkg=包名@版本号 就能定向加载。

我实测了一个 2017 年的旧版本 Python，操作流程是这样的：
1. 在浏览器地址栏输入：https://trynix.dev/[email protected]
2. 页面加载后，点击那个明显的 "Load" 按钮。
3. 等待几秒钟（取决于浏览器对 WebAssembly 的解析速度），你会直接进入一个交互式 Shell。
4. 输入 python3 --version，确认显示为 Python 3.6.2。

整个过程没有任何安装步骤，也没有登录环节。对于那些需要快速验证某个旧版本依赖，或者想给别人演示一个特定环境 Bug 的开发者来说，这简直是神级工具。

它的底层逻辑和实际体验

这里面用到了 qemu-wasm，这意味着整个 x86_64 Linux 虚拟机是跑在 WebAssembly 里的。我试了一下，虽然是虚拟机，但响应速度比我想象中快得多，并没有明显的卡顿感。

不过有几点实操后的真实感受，大家在用的时候要注意：

• 启动耗时： 点击 "Load" 到进入 Shell 大约需要 3-8 秒，这取决于你的设备性能。
• 持久化问题： 这是一个纯前端的虚拟机，刷新页面或者关闭标签页后，你在这个环境里做的所有修改都会丢失。它适合做「一次性验证」，不适合当成持久化开发环境。
• 资源占用： 跑 qemu-wasm 比较吃内存，如果同时开几十个这样的标签页，浏览器可能会变得很慢。

怎么把这个能力集成到 GitHub PR 评审里

除了手动访问，这个项目最让我兴奋的是它的 trynix-preview GitHub Action。

很多时候我们审 PR 看到代码改动，很难直观感受到运行效果，除非自己把分支拉下来、配环境、跑起来。而这个 Action 可以自动在 PR 的评论区贴一个链接。点击链接，它会直接在浏览器里引导你 Boot 那个 PR 的构建版本。

这种「无需服务器，仅靠浏览器」的预览方式非常优雅。它避免了传统的 Preview Environment 需要部署一套 K8s 或者是临时容器的复杂成本。对于开源项目维护者来说，这极大地降低了验证 PR 的心智负担。

适用场景与替代方案对比

如果你在犹豫用这个还是用传统的远程开发环境，可以参考我的判断：

• 用 trynix.dev 的场景： 快速测试一个 Nix 包、给他人发送一个可运行的特定版本环境、在没有权限安装软件的机器上临时用个 Linux 工具。
• 别用它的场景： 需要大规模编译代码（速度太慢）、需要挂载本地大文件、或者需要长期保存状态。

相比于传统的云端 IDE 或 Docker 容器，它的优势在于「零部署」和「URL 传递」。你不需要给对方开权限，也不需要对方安装 Docker，只要发一个链接，对方点开就是你要的环境。