通常，前端库的发布流程只有几条路：从 npm 安装、通过 CDN 引入，或者下载仓库中的构建产物。htmx 4.0 却把这套惯例翻了过来：开发者需要打通四个关卡、击败最终 BOSS，再从一张实体 Game Boy / Game Boy Color 卡带中读取源码。
7 月 26 日，htmx 作者 Carson Gross 在官方周边商店上架了售价 25 美元的「htmx 4: the game」。这不只是把 Logo 印在卡带上的纪念品，而是把“获得源码”设计成了游戏奖励。对一个强调 HTML、超媒体和低复杂度的项目来说，这种发布方式既荒诞，又准确地延续了它的社区气质。
当软件发布不再只是包管理器的一行命令
成熟 JavaScript 项目的发布链路往往高度标准化：CI 构建文件，registry 保存版本，lockfile 固定依赖，CDN 负责分发。效率很高，但每次发布也因此越来越像一次后台任务。
Game Boy 卡带把几个原本被基础设施隐藏的问题重新摆到了桌面上：
- 软件一定要通过包管理器交付吗？
- 源码是随手下载的文件，还是可以成为作品的一部分？
- 一个版本的发布，能否同时是一场社区活动？
- 当载体变成实体硬件，开发者如何验证读到的内容没有损坏？
当然，卡带不适合承担常规依赖分发。它没有 npm 的版本解析，也无法自然接入自动化构建。它的价值更接近限量实体发行、互动文档和技术玩笑的交集：正常渠道解决生产使用，特殊载体制造记忆点。
真正有意思的是“源码如何离开卡带”
摘要没有给出卡带内部格式、通关后源码的保存位置，也没有说明是否需要专用读取器。因此，下面不能当作该产品的官方提取说明，只能作为拿到合法 ROM dump 后的实践思路。
Game Boy ROM 本质上是二进制镜像。如果源码以明文、压缩数据或游戏资源的形式存放，分析路径通常包括：确认文件、计算哈希、搜索文本标记，再根据实际格式提取内容。
假设你已经通过自有卡带和合规设备得到 htmx4.gb，可以这样实践：
# 确认文件类型和大小
file htmx4.gb
wc -c htmx4.gb
# 记录哈希，避免后续分析时混淆不同 dump
sha256sum htmx4.gb
# 搜索可能出现的源码标记
strings -a -n 8 htmx4.gb | rg -n "htmx|function|XMLHttpRequest|fetch|<script"
# 查看疑似命中位置附近的原始字节
xxd -g 1 htmx4.gb | less
macOS 默认没有 sha256sum 时，可以改用：
shasum -a 256 htmx4.gb
strings 只能发现未压缩的可打印文本。如果搜索不到内容，并不意味着卡带里没有源码；数据可能经过压缩、编码、分块，或者只有通关后的游戏逻辑才会把它写入存档。进一步分析前，应先确认卡带说明和作者提供的读取方式，避免把猜测当成文件格式。
提取后先验证，再放进项目
即使成功得到一个 JavaScript 文件，也不应该立刻替换生产环境中的依赖。至少要检查文件边界、语法和哈希，并在隔离页面中观察实际行为。
假设提取结果名为 htmx-4.js，可以先做一轮最小验证：
# 查看头尾，排除游戏文本或二进制垃圾混入源码
head -n 20 htmx-4.js
tail -n 20 htmx-4.js
# 用 Node.js 只做语法检查，不执行文件
node --check htmx-4.js
# 保存提取产物的校验值
sha256sum htmx-4.js > htmx-4.js.sha256
接着可以建立一个不连接业务系统的测试目录：
mkdir -p htmx4-lab
cp htmx-4.js htmx4-lab/
cd htmx4-lab
python3 -m http.server 8080
在同一目录创建 index.html。下面示例只验证脚本能否被浏览器加载；其中使用的具体属性和 API 仍需根据最终拿到的 htmx 4.0 源码或文档调整：
<!doctype html>
<html lang="zh-CN">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>htmx 4.0 本地验证</title>
<script src="./htmx-4.js" defer></script>
</head>
<body>
<h1>本地加载测试</h1>
<p>打开开发者工具，检查脚本加载状态和控制台错误。</p>
</body>
</html>
浏览器访问 http://localhost:8080 后，应重点检查 Network 面板中的 HTTP 状态、响应类型和文件大小，同时确认控制台没有语法错误。不要直接使用 file:// 打开页面，因为浏览器对本地文件的安全限制可能掩盖真实问题。
纪念品、发布渠道和供应链边界
这张卡带很容易让人产生一个浪漫的结论：未来的软件都可以绕开 registry，回到实体介质。工程上并非如此。
实体卡带会带来额外边界：硬件批次可能不同，ROM dump 可能损坏，用户上传的镜像可能被篡改，非官方提取脚本也可能执行恶意代码。更重要的是，团队需要可重复构建、版本标识、许可证文本、变更日志和可验证校验值，仅有一份从卡带中读出的 JavaScript 文件并不能替代这些机制。
因此，较稳妥的采用清单是：
- 把卡带视为收藏品和交互式发行实验，而不是默认生产依赖源。
- 只读取自己合法持有的介质，并遵守相关许可证和当地法律。
- 对 ROM 与提取文件分别计算哈希，保留读取设备和工具版本。
- 在隔离环境中做静态检查和浏览器测试，不执行来历不明的提取程序。
- 等待项目提供正式文档、版本标记和常规分发渠道后，再评估生产升级。
htmx 4.0 的卡带发布真正值得关注的，不是让开发者以后都用复古硬件安装依赖，而是提醒我们：软件版本也可以被设计成一件作品。只是当它从趣味发行进入生产系统时，校验、可重复性和供应链安全仍然一项都不能少。