网页转 Markdown 工具怎么选：从“抓取成功”到“内容可用”

网页转 Markdown 看起来像一个简单任务：输入 URL，输出文字。实际使用时，它同时涉及网络访问、页面渲染、正文识别、资源处理和格式转换。工具展示页里的一个成功示例，无法代表它能处理你的真实页面集合。

选择这类工具时，最好把“是否成功”拆成三个层级：请求是否到达页面、是否提取到主要内容、结果是否能直接进入下一步。只有第三层成立，转换才真正创造了价值。

先准备一组有差异的测试网页

不要只测试自己的首页。建立一个五到十个 URL 的固定样本集，至少包含：普通服务端渲染文章、依赖 JavaScript 的页面、带代码块和表格的文档、内容较长的中文页面、重定向页面，以及一个预期应该失败的受限地址。

固定样本的意义在于可重复比较。以后更换工具、升级版本或修改参数时，可以再次执行同一组任务，而不是依靠“这次看起来不错”的印象。

为每个样本写下预期：标题、正文起止位置、必须保留的链接或图片、允许删除的导航和推荐区。这样评估时不会被输出篇幅迷惑。

内容完整性比字符数量更重要

输出很长不一定代表内容完整。页头菜单、页脚、相关推荐和 Cookie 提示会增加大量字符，却可能遗漏文章中间的表格或代码。

检查结果时，可以逐项确认标题层级、段落顺序、列表嵌套、表格、代码块、引用和脚注。对于研究用途，链接文字和目标地址也非常重要；只留下文字而丢失链接，会让来源核验变得困难。

图片不一定必须下载到本地，但工具至少应提供清楚的图片 URL 和替代文本。如果原图使用懒加载、srcset 或脚本注入，也要检查是否拿到了真正资源，而不是占位图。

正文提取需要可解释的边界

有些任务需要整页 DOM，有些任务只需要文章正文。优秀的工具应当让调用者明确选择，而不是把一个不可解释的“智能清理”应用到所有页面。

正文模式应尽量删除导航、广告、登录提示和推荐列表，同时保留文章内部的小标题、提示框和必要元数据。整页模式则应该尽可能忠实，方便后续自己处理。

如果工具提供清理规则，检查规则是按选择器、内容区域还是通用算法配置。可配置不一定意味着复杂；一个明确的内容模式参数，通常比大量隐藏启发式更容易维护。

动态渲染不是越久越好

对于依赖 JavaScript 的页面，浏览器渲染确实能拿到更多内容，但也会增加等待时间、资源消耗和失败概率。关键不是“是否支持浏览器”，而是能否控制渲染条件。

检查是否可以设置超时、等待某个元素、延迟一小段时间，以及禁用不必要的媒体资源。固定等待十秒可能在一个页面上有效，却会让一千个批量任务变得昂贵。

还要区分页面没有内容和渲染失败。错误结果应该告诉调用者是 DNS、超时、状态码、访问限制还是内容提取失败，方便决定重试、跳过或转人工。

安全边界必须在网络请求之前生效

只要工具允许用户提交 URL，就需要考虑内网地址、云元数据地址、重定向和特殊协议。安全检查不能只验证第一次输入；每一次重定向后的目标都要重新判断。

同时限制响应体大小、重定向次数、总超时和允许的协议。网页抓取经常面对不可控服务器，缺少这些限制会让一个普通内容功能变成资源耗尽或内部网络访问入口。

如果工具需要登录 Cookie 或自定义请求头，应当明确这些敏感信息的存储、日志和作用域。不要为了抓取一个公开页面，默认把完整浏览器会话交给第三方。

批量使用要看缓存和可复现性

批量转换时，缓存可以显著降低重复请求，但缓存键必须包含会影响结果的参数，例如内容模式、渲染设置和请求语言。否则同一个 URL 的不同任务可能互相污染。

结果最好记录抓取时间、最终 URL、页面状态和转换版本。网页会变化，没有这些信息时，你很难解释为什么同一个任务两天后得到不同内容。

测试一百个页面时，不要只看成功率。还要统计空正文、明显截断、格式损坏和需要人工修正的比例。一个返回 98 个“成功”响应、但其中二十个不可用的工具，实际可靠性并不是 98%。

最终选择应当回到用途：临时复制文章、建立搜索索引、给 AI 提供上下文和长期归档，对结构、安全与可追溯性的要求完全不同。先定义下游需要什么，再判断哪个工具的输出最接近那个接口。