网页下载工具对比：它们保留了什么，又破坏了什么

一个周末，某托管公司突然对客户关停了服务。当然，没有备份。周一早上网站还在勉强响应，我做的第一件事就是用网页下载器把所有还能访问的页面抓下来，趁它彻底下线之前。这就是这类工具的用途：在服务器停止响应之前，快速抓取它还能给你的东西。

不过，网页下载器并非万能。人们实际常用的四种工具, HTTrack、SiteSucker、wget 和浏览器自带的保存功能, 在保留内容方面差异很大。以下是每种工具保存了什么、悄悄破坏了什么，以及如何选择。

网页下载器实际保存了什么

所有网页下载器的底层工作方式都一样：请求一个 URL，解析返回的 HTML，找到其中链接的资源和内部链接，下载这些内容，重写链接使其能在本地磁盘上正常工作，然后不断重复直到队列为空。本质上就是一个带保存按钮的爬虫。

最终保存到你硬盘上的内容：

• HTML 页面，通常会重命名以便在本地无需服务器即可打开
• 这些页面引用的 CSS、JavaScript 和字体
• 图片、视频、PDF 以及页面直接链接到的任何其他文件
• 与原始 URL 结构对应的文件夹层级

不会保存的内容：任何服务器动态生成的东西。下载器收到的 HTML 和任何匿名访客看到的一样, PHP 代码、数据库、管理后台、订单历史，这些都不会通过网络传输，自然也不会保存到本地。下载下来的 WordPress 网站只是它的一尊雕像，而非网站本身。

有两个范围细节决定了最终结果。第一是发现机制：爬虫只能找到已抓取页面中链接的 URL，加上你手动提供的 sitemap, 没有入站链接的孤立页面将始终不可见。第二是礼貌策略：大多数工具默认遵守 robots.txt，虽然 HTTrack 允许你覆盖这一设置，但只应在你自己拥有的网站上这样做。

HTTrack 和 SiteSucker：图形界面选项

HTTrack（Windows 上叫 WinHTTrack）是这个类别的鼻祖：免费、开源，从 1998 年就有了。粘贴一个 URL，选择项目文件夹，它就能镜像整个网站。真正的价值在于它的选项, 爬取深度限制、文件类型过滤、带宽上限，以及包含或排除 URL 模式的扫描规则。我用它在大约二十分钟内镜像了一个 400 页的摄影师作品集，包括所有图片。

我通常会修改的默认设置：

• 最大镜像深度：小型站点保持无限，大型站点限制在 3 或 4 层
• 扫描规则：添加目标域名的包含模式，防止爬虫跑到站外
• 流量控制：对于非自己的服务器，使用 2 到 4 个连接并设置带宽限制
• MIME 类型：首轮排除视频, 一个被遗忘的网络研讨会文件夹可能就有 40 GB

缺点：界面看起来很有年代感，最后一次有意义的更新已经是几年前的事了，而且对 JavaScript 完全无感知。如果页面内容是在浏览器中通过 JavaScript 构建的，HTTrack 只会保存一个空壳。

SiteSucker 是 Mac 上的对应选择，在 App Store 上售价几美元。粘贴 URL，点击开始，它就会在后台以合理的默认设置下载，支持暂停和恢复。可调选项比 HTTrack 少，同样对 JavaScript 无感知，但如果想在 macOS 上快速获得一个干净的镜像，它是最省事的选择。

wget：给喜欢命令行的人

wget 是可脚本化的选项，几乎每台 Linux 机器上都预装了，Mac 上只需一条 brew install 即可。经典的完整镜像命令：

wget --mirror --convert-links --adjust-extension --page-requisites --no-parent https://example.com

每个参数的作用：

• --mirror 开启递归和时间戳，重复运行时只抓取有变化的文件
• --convert-links 在下载后重写链接，使页面可离线访问
• --adjust-extension 将服务器生成的页面保存为标准的.html 文件
• --page-requisites 抓取每个页面渲染所需的 CSS、JS 和图片
• --no-parent 将爬取范围限制在起始路径之下，而不是吞掉整个域名

值得了解的补充参数：--wait=1 --random-wait 让你对小型服务器保持礼貌，-c 可恢复中断的镜像而无需重新下载已完成的文件，--load-cookies 配合导出的 cookie 文件可以抓取需要登录的页面。另外，不要把 wget 和 curl 混淆, curl 擅长抓取单个 URL，wget 则用于镜像整个网站。人们经常把它们搞混。

浏览器保存：内置选项

Ctrl+S，网页完整保存, 你已经拥有的下载器。它保存一个页面加上一个资源文件夹。对于一张收据、一篇文章或一个你现在就需要联系页面来说，这就够了。它甚至有一个真正的超能力：浏览器在 JavaScript 执行后保存页面，所以 wget 只能拿到空壳的 React 重度页面，在这里能完整渲染保存。

局限性很快就会显现。CSS 背景图片和 @import 链经常丢失，链接指向线上网站而非彼此之间，而且没有递归, 一个 300 页的网站意味着要手动保存 300 次。一个值得了解的技巧：SingleFile 扩展会在 JavaScript 执行后将所有资源内联到一个自包含的 HTML 文件中。对于归档单个 JS 重度页面，它完胜普通的 Ctrl+S。另存为 PDF 则是另一回事：它捕获的是外观而非页面本身，里面的任何东西都无法正常工作。

一次网页下载的完整流程

第一次镜像一个不熟悉的网站，按流程来会更顺利。我的做法是：

1. 爬取前检查 robots.txt 和网站条款, 无论服务器大小都使用 wait 参数。
2. 确定范围：整个域名还是一个分区。使用 no-parent 规则或 HTTrack 扫描规则，防止博客爬取吞掉旁边的商店。
3. 运行镜像并查看日志。反复出现 403 说明被反爬检测拦截；大量日历或标签页说明范围在泄漏。
4. 随机抽查十个离线页面，包括一个带联系表单的和一个图片量大的。现在坏了就永远坏了。
5. 将本地文件数量与网站 sitemap 对比。差距大说明 JavaScript 渲染的内容或范围规则吃掉了页面。

所有网页下载器都会破坏的东西

选上面任何一个工具，同样的问题都会出现，因为问题出在媒介本身，而非软件：

还要注意跨域资源。大多数爬虫默认只留在起始主机上，所以从 CDN 子域名提供的图片或外部主机的字体会被跳过，除非你扩大范围, 而扩大范围后，保存的页面又会带回一堆失效引用。还有 SEO 残留问题：canonical 标签、Open Graph URL 和绝对内部链接仍然指向旧域名。在个人归档中无害，但如果镜像重新上线就是真正的问题。

下载的网站是一尊雕像：看起来完全正确，但里面什么都不会动。

什么时候不该用网页下载器

最明显的情况：网站已经下线。下载器需要一个响应请求的在线服务器，过期的域名或已死的主机给不了它任何可爬取的内容。幸存的副本在 Wayback Machine 里, 而用 wget 去爬 web.archive.org 是一种折磨：请求被限速、被改写的 URL、每页注入的工具栏，以及散落在不同年份的快照。

这正是 网站恢复服务 存在的意义。它从归档快照恢复网站，支持按日期范围选择，剥离归档冗余代码和旧的分析脚本，并在你付费前展示确切的归档文件数量、总大小和锁定价格。

第二种不该用的情况：你要的是内容而非像素, 把文章导入表格，把产品导入数据库。那是数据提取，不是下载。第三种：如果网站需要恢复数据库驱动的功能, 比如商店、论坛, 静态镜像只能给你外观，不能给你功能。你需要的是恢复加一个新的后端。

从文件到重新上线的网站

一个镜像文件夹不是网站。让它重新上线意味着要找地方托管、修复绝对链接、移除失效的跟踪脚本、配置 HTTPS。这些可以手动完成, 或者跳过这些繁琐工作：Restorix 将恢复的网站直接部署到 SSH/SFTP、FTP/FTPS 或 S3，并附带一个轻量级 CMS，让网站可以再次编辑，而不仅仅是可浏览。无论哪种方式，完成前请在手机上测试一下效果。