Kage 开源：把动态网站渲染成无脚本离线包

一个网页今天能打开，不代表几年后还能打开。

更麻烦的是，很多网页现在不是一份 HTML，而是一堆前端脚本、远程接口、CDN 资源和第三方代码临时拼出来的页面。你点“另存为”，存下来的可能只是一个壳。

Kage 有意思的地方就在这里。它不是直接保存源码，而是先用 Headless Chrome 把网页真正渲染出来，再截取最终 DOM，移除 JavaScript，并把 CSS、图片、字体等资源改成本地路径。

我的判断是：Kage 的价值不在“克隆一个网站”，而在“冻结一批可读内容”。这对长期保存网页资料的人，比一个随时会断链的 HTML 文件更实用。

Kage 解决的是网页保存的失效点

Kage 是 Go 编写的开源 CLI，仓库是 tamnd/kage，采用 MIT 许可证。默认情况下，它需要本机有 Chrome 或 Chromium；如果用容器镜像，里面已经内置 Chromium。

它的主要命令很少，逻辑也清楚：

关键动作发生在 clone 阶段。

传统网页保存拿到的常常是初始 HTML。Kage 会先让 Chrome 像浏览器一样打开页面，等内容加载完成后，再保存渲染后的 DOM。随后它会剥离脚本、事件处理器和 javascript: URL。

这条路线的好处很直白：页面内容尽量留下来，运行时依赖尽量拿掉。

代价也同样直白：脚本没了，交互就没了。

这也是它和普通“网页另存为”的分界线。Kage 更像一次渲染后的归档，而不是一次功能复制。

真正有用的是可打包、可分发

Kage 的 clone 默认会遵守 robots.txt。它可以从 sitemap.xml 起步，支持断点续跑，也支持用 --refresh 重新渲染已有镜像。

它还提供一些控制范围的能力，比如 --scope-prefix 限定路径，--subdomains 扩展到子域名，--scroll 触发懒加载资源。忽略 robots 需要显式使用 --no-robots。

这个细节很重要。Kage 的定位不是绕过网站限制，也不是反爬工具。它更接近一个规矩的离线归档流水线。

真正拉开距离的是 pack。

Kage 可以把镜像目录打包成 ZIM。ZIM 是开放的离线内容格式，Kiwix 生态可以读取。Kiwix 常被用来离线阅读 Wikipedia、Stack Overflow、Project Gutenberg 等内容，所以 ZIM 有相对成熟的阅读器环境。

Kage 也支持生成自包含可执行文件。做法是把归档附加到 Kage 本体上，运行后直接提供离线站点服务。

这对分发很有用。你不一定要让接收方先安装 Kage，也不一定要求对方理解镜像目录结构。

但这里不能夸大。这个可执行文件不是跨平台通用的“万能单文件”。它仍然和目标系统、CPU 架构相关。默认会基于当前机器的 Kage 生成；跨平台分发时，需要准备对应平台的 base 二进制。

最相关的两类人，可以怎么用

最直接受影响的是两类人。

一类是需要长期保存网页资料的开发者和研究者。比如保存某个开源项目的文档、论文资料页、技术博客、在线手册。对他们来说，动作可以很具体：用 clone 冻结一份当前版本，用 serve 检查可读性，再用 pack 打成 ZIM 放进资料库。

另一类是需要离线分发内容的技术用户。比如把课程材料、内部文档、弱网环境下要用的网页资料发给别人。对他们来说，Kage 的收益不是“页面还能不能动”，而是“内容能不能在没有网络时稳定打开”。

这也决定了 Kage 不适合谁。

依赖登录、评论、站内搜索、地图、复杂表单、前端路由和实时数据的应用型网站，保存后通常只能保留当时可见的内容。原有交互不会一起保留下来。

Kage 生成的 ZIM 目前也不能直接等同于 Kiwix 官方内容包。材料里提到的能力更偏浏览和点击；完整全文搜索索引这类离线阅读体验，目前还看不清。

所以判断 Kage 值不值得用，不该问“它能不能完整保存一个网站”。更该问的是：你要保存的是内容，还是功能？

如果是内容，Kage 的路线很清楚。先渲染，再去脚本，再本地化资源，最后打包。

如果是功能，它的边界也很清楚。脚本一删，很多动态能力就不会回来。

后面要看的变量不多：复杂前端站点的渲染稳定性，ZIM 与 Kiwix 的兼容细节，离线搜索索引会不会补上。只要这三点继续变好，Kage 对资料归档人群的价值就会更实在。

回到开头那个问题：网页不是存下来就等于保存了。

能把一批动态页面变成可读、少依赖、可分发的离线包，已经解决了很多人真正卡住的那一步。