kage用无头浏览器渲染后封印网站彻底告别 JS 幽灵依赖核心问题你保存的网页真的是你的吗每个人都遇到过这种情况把某篇文章另存为几年后打开是一片空白。原因很清楚——现代网页本质上是一个薄客户端内容由远端 JavaScript 在运行时注入。你存下来的只是一个壳它需要不断向别人的服务器打电话才能变成你看过的样子。这不是保存是借阅。kage日语「影」意为影子正面解决的就是这个问题。它由 Go 编写MIT 开源核心思路是先让页面活一次再把它钉死。关键机制渲染快照 外科手术式去脚本kage 的巧妙之处不在于抓取而在于介入时机。传统工具HTTrack、wget在 HTTP 层抓取拿到的是服务器吐出的原始 HTML——对于现代 SPA 或动态加载内容这基本等于拿到了一个空骨架。而 kage 的流程是用真实的 Headless Chrome 打开页面等待页面完全渲染包括 JS 执行后动态注入的 DOM快照此刻人类能看到的 DOM外科手术式移除所有script标签、事件监听、javascript:URL将 CSS、图片、字体等静态资源下载到本地路径。这个渲染完再截图的思路让 kage 相比传统爬虫有了质的差异它保存的是渲染结果而非渲染材料。历史脉络与同类工具对比工具抓取方式能处理动态内容输出形式是否保留 JSHTTrack / wgetHTTP 层静态下载✗ 基本不行文件夹是但 JS 无法执行浏览器另存为当前页面快照△ 当前帧可以单 HTML 文件夹是且有外链依赖MonolithRustHTTP 层下载 内联✗ 无浏览器渲染单 HTML 文件是全部内联SingleFile浏览器扩展浏览器内运行✅ 当前页有效单 HTML 文件是内联kageHeadless Chrome 渲染✅ 等待 JS 执行完文件夹 / ZIM / 二进制删除这里有一个根本的取舍Monolith 和 SingleFile 把 JS保留并内联而 kage 把 JS删除。Monolith 在 GitHub 有 13,000 star但它不使用 Headless Browser官方文档明确注明动态内容是其局限。kage 用更重的方案启动真实 Chrome换来了渲染能力但代价是删掉 JS 之后一切交互搜索、登录、地图、路由、评论也一起消失了。这是设计选择不是缺陷前提是你想要的是内容不是功能。输出格式的分层设计三个用途三种形态# 第一层克隆为本地文件夹可检查、可浏览 kage clone paulgraham.com --max-pages 50 --scroll # 第二层打包成 ZIM 归档开放格式可用 Kiwix 生态打开 kage pack paulgraham.com kage open paulgraham.com.zim # 第三层打包成独立可执行文件无需任何依赖双击即开 kage pack paulgraham.com --format binary -o paulgraham ./paulgraham # 跨平台构建在 Mac 上生成 Windows 查看器 kage pack paulgraham.com --format binary --base kage-windows-amd64.exeZIM 是值得单独关注的格式选择。它是 Kiwix 生态的基础格式支撑着 Wikipedia 离线版、Stack Overflow 离线版在船上、无网络教室里的使用。用开放标准格式意味着你今天生成的.zim文件10 年后依然能被任何 ZIM 阅读器打开你不被 kage 锁定。这个设计决策比功能本身更值得注意。自包含二进制更激进把 kage 本身和站点内容打包成一个约 13 MiB 站点大小的可执行文件对方什么都不需要安装运行即可。代价也直接每个文件都带着一整个 kage内容很小时极度浪费空间。交叉验证信源一ic.work 独立分析2026年6月ic.work 上的分析文章明确指出kage 的价值不是完整复制网站功能而是冻结可读内容并指出 ZIM 格式目前不支持全文搜索索引原文也有此说明以及跨平台二进制需针对目标平台单独编译——这些局限与原 README 一致属于认同并补充细节没有反驳。信源二dev.to 对 Monolith 的介绍2025年6月13,751 GitHub starMonolith 是 kage 最直接的横向竞品用 Rust 编写生成单个内联 HTML 文件但不使用 Headless Browser官方文档和第三方分析均注明其不处理动态内容。这从侧面验证了原文的立论在 JS 驱动的现代网页面前不经过真实浏览器渲染就无法获得完整内容。kage 选择用更重的方案解决这个问题Monolith 选择不解决。两者适用场景不同并非 kage 全面优于 Monolith但在动态内容保存这个维度原文的判断站得住脚。诚实的边界kage 被过度解读的风险在于克隆整站这个说法太诱人。以下场景它做不了登录墙后的内容kage 本身无法处理需要身份验证才能访问的页面除非你自行配置 Cookie前端路由 SPAReact/Vue 构建的单页应用URL 靠 JS 路由管理kage 的链接追踪会失效无限滚动/分页内容--scroll可以触发懒加载但对真正无限分页的平台Twitter、Instagram效果有限ZIM 全文搜索打包后无法在 kage 的 ZIM 里做站内关键词搜索这个功能目前缺失动态交互完全丧失删 JS 是设计目标但站内搜索、过滤器、折叠/展开这类 UI 行为同样消失可读性取决于站点的内容结构本身。还有一个实际问题kage 依赖 Chrome/Chromium在 CI 环境或轻量服务器上这是一个不轻的依赖。Docker 镜像打包了 Chromium 解决了这个问题但又引入了容器依赖。个人启发该如何实际应用这个工具最直接的价值场景是技术文档归档把你依赖的开源项目文档、API 文档、学习资料克隆下来打成 ZIM。文档类网站通常是静态生成的JS 交互少kage 效果最好且原始内容本身就值得长期保存。具体可以做的动作立刻执行一次选 3 个你最常用但担心消失的技术文档网站比如go.dev/doc、某个库的旧版文档运行kage clone [url] --scope-prefix /doc选 ZIM 而非二进制优先打包成.zim因为格式开放Kiwix 桌面/移动端都能读而且你未来某天决定不用 kage 了内容依然可访问不要对社交媒体站点抱期望kage 对 SPA 重度依赖的站点效果差用在内容型网站上。推演接下来会怎样kage 目前处于工具链形成期不是范式突破而是把Headless Browser 去脚本 多格式输出这条路走通的早期完整实现。可以预见ZIM 全文索引会补上因为这是 Kiwix 生态的标配没有它与官方内容包的互操作性就差一截SPA 站点支持会改善Headless Chrome 的 CDPChrome DevTools Protocol已经足够强大可以等待特定路由渲染完成这只是工程实现问题类似工具会整合 kage 的思路先渲染后封印这条路径会逐渐成为网页归档工具的标准范式就像 Puppeteer 出现后 SSR 快照方案被广泛采用一样。延伸思考内容归档与功能复制的边界在哪里kage 选择删 JS 是一个极端但清晰的立场。未来是否存在一种方案能在删除追踪/网络调用的同时保留纯前端交互逻辑比如折叠/展开、本地过滤Service Worker 沙箱或许是一个方向。网页的长期可访问性谁来负责kage 是个人工具Kiwix 是社区方案Internet Archive 是机构方案。三者覆盖不同的时间尺度和内容规模——但对于个人依赖的小众技术文档没有任何一个机构会主动帮你保存这件事只能靠自己。Headless Browser 渲染作为内容提取基础设施的边界在哪kage 用它做离线保存其他工具用它做测试、截图、SEO 预渲染。当 Chrome 的 CDP 协议成为事实标准后基于它的工具生态会走向何方——是被 Google 统一管控还是成为真正的开放基础设施 参考来源GitHub - tamnd/kage: Shadow any website for offline viewing, with the JavaScript stripped out · GitHub