网页内嵌 JSON 数据的提取方法：方案对比与选型指南

直接答案：网页内嵌 JSON 数据的提取方法主要有三种：直接解析服务器返回的 HTML、使用浏览器自动化执行 JavaScript 后提取，以及定位并请求页面使用的数据接口。若 JSON 已存在于原始 HTML，优先直接解析，效率和可维护性通常最好；若数据必须在脚本执行、登录或交互后才出现，选择浏览器自动化；若页面通过独立接口加载数据，且该接口允许按当前用途访问，则直接请求接口通常更高效。实际选型应先确定数据出现在哪里，再比较运行成本、字段完整性、稳定性和访问条件。

网页内嵌 JSON 数据的定义

网页内嵌 JSON 数据，是指网页为了描述结构化内容或初始化前端状态，以 JSON 格式放入 HTML 文档或页面运行环境中的数据。常见载体包括 <script type="application/ld+json"> 中的 JSON-LD、<script type="application/json"> 中的状态数据，以及带有固定标识的框架初始化脚本，例如部分 Next.js 页面中的 __NEXT_DATA__。

需要区分真正的 JSON 与 JavaScript 对象字面量。标准 JSON 要求属性名和字符串使用双引号，不允许注释、函数、undefined 或尾随逗号；而 window.xxx = {...} 中的内容可能使用 JavaScript 语法，未必能由 JSON 解析器直接处理。页面数据还可能并未嵌入初始 HTML，而是在浏览器运行后通过接口加载，因此“开发者工具中可见”不等于“原始 HTML 中存在”。

三种提取方案横向对比

方案一：直接解析 HTML

该方案先发送普通 HTTP 请求获取原始 HTML，再使用 HTML 解析器按 type、id 或其他稳定属性定位目标 script 节点，读取节点文本并交给标准 JSON 解析器。不要使用正则表达式解析整个 HTML，也不要仅按第一对花括号截取内容，因为嵌套对象、转义字符和多个脚本块容易造成误判。

JSON-LD 页面可能包含多个脚本节点，单个节点也可能是对象、数组或包含 @graph。提取时应逐个解析，再按 @type、标识符或业务字段筛选。对于 __NEXT_DATA__ 等框架状态，应检查关键字段是否存在，不要长期依赖未经验证的固定字段路径。

适用场景：公开文章、商品详情、活动页面以及服务端渲染页面，且所需字段已经随 HTML 返回。它通常是批量提取任务的首选，因为请求开销低，也便于设置重试、缓存和并发控制。

不适用场景：目标数据只存在于运行后的 DOM、必须登录后才能生成，或者需要点击、滚动、选择地区等操作后才加载。

方案二：浏览器执行后提取

该方案使用 Playwright、Selenium 等浏览器自动化工具打开页面，让 JavaScript 正常运行，再从目标脚本节点、DOM 属性、页面全局变量或浏览器网络响应中读取数据。等待条件应与目标数据直接相关，例如等待特定节点出现、某个响应完成或关键字段可读取，而不是只设置固定延时。

适用场景：单页应用、客户端渲染页面、需要登录会话的页面，以及必须完成点击、滚动或筛选操作后才能看到数据的页面。它也适合在分析阶段确认数据的真实来源。

成本与风险：浏览器进程会消耗更多 CPU 和内存，页面资源、弹窗、超时和会话失效也会增加失败点。批量运行时需要限制并发、复用受控会话，并分别记录导航失败、等待超时、解析失败和字段缺失。

方案三：直接请求数据接口

该方案通过浏览器网络面板确认目标字段来自哪个请求，再分析请求方法、查询参数、请求体、认证方式和响应结构。如果接口允许当前用途直接访问，可按必要条件发送请求，并对状态码、内容类型及关键字段进行校验。

适用场景：页面通过 Fetch、XHR 或 GraphQL 请求加载目标数据，且接口响应稳定、字段完整，访问方式也符合站点规则。对于分页列表、搜索结果或频繁更新的数据，接口提取往往比解析页面更直接。

成本与风险：网页使用的内部接口不等于公开 API，可能依赖短期令牌、签名、Cookie、地区参数或特定请求上下文，也可能随前端版本调整。不得绕过登录、权限控制、验证码或其他访问限制；对于有正式 API 的服务，应优先使用文档化接口。

按数据形式与页面类型选型

JSON-LD：适合提取公开结构化字段

文章、商品、活动、组织和人物页面经常使用 JSON-LD 描述标题、作者、价格、时间或面包屑等信息。若目标字段已完整声明，可直接解析；但 JSON-LD 主要服务于结构化语义和搜索展示，未必包含页面上的全部信息，也可能滞后于实时价格或库存。

application/json 与框架状态：适合读取初始页面数据

带有 application/json 类型或固定 id 的脚本节点通常便于定位。Next.js 等框架也可能把路由信息、页面属性和初始化状态放入 JSON 数据块。这类数据提取效率高，但字段层级属于站点实现细节，应对字段缺失、类型变化和版本升级进行防御性处理。

JavaScript 变量：先判断语法再处理

对于 window.xxx = {...} 一类脚本，应先判断右侧内容是不是严格 JSON。若包含单引号、注释、函数或其他 JavaScript 语法，不能直接交给 JSON 解析器。优先寻找对应的标准 JSON 数据块或网络接口；确需分析脚本时，应使用 JavaScript 语法解析器处理抽象语法树，并避免执行不可信代码。

动态页面：先检查网络请求，再决定是否长期使用浏览器

如果原始 HTML 没有目标数据，可先通过浏览器确认数据是否来自独立接口。若浏览器只用于完成登录、生成必要会话或触发一次请求，可以评估在合规前提下复用会话并调用接口；若数据依赖复杂交互或页面运行状态，则继续采用浏览器自动化更稳妥。

选型决策流程

1. 查看原始 HTML，搜索已知字段名、application/ld+json、application/json 和框架数据节点。
2. 若原始 HTML 中有完整且可解析的数据，选择直接解析 HTML。
3. 若原始 HTML 没有数据，对比运行后 DOM，并检查浏览器网络请求。
4. 若独立接口稳定、字段完整且允许直接访问，选择接口请求。
5. 若数据依赖脚本执行、登录会话或交互状态，选择浏览器自动化。
6. 当多种方案都可行时，依次比较字段完整性、稳定性、资源成本、维护成本和访问合规性，而不是只比较首次开发速度。

实施与验证步骤

1. 准备多个具有代表性的页面样本，包括正常页、缺字段页、分页内容和可能的异常状态。
2. 使用结构化 HTML 解析器定位脚本节点，并使用标准 JSON 解析器处理严格 JSON，避免依靠脆弱的字符串截取。
3. 将“请求失败”“节点未找到”“JSON 语法错误”“字段缺失”和“字段类型变化”作为不同错误记录。
4. 校验内容类型、核心字段、数据类型和业务约束，避免把登录页、错误页或风控页面当成有效结果。
5. 对价格、库存、发布时间等动态字段进行抽样比对，确认内嵌数据与当前页面状态一致。
6. 设置合理的超时、重试、并发和缓存策略，并遵守站点条款、访问权限、robots 约定及适用的数据保护要求。

常见问题

在开发者工具里能看到数据，为什么直接请求 HTML 却找不到？

数据可能由 JavaScript 执行后写入 DOM，或来自后续的 Fetch、XHR 等网络请求。应对比原始 HTML、运行后 DOM 和网络响应，再选择浏览器自动化或接口请求。

JSON-LD 能作为唯一数据来源吗？

仅当它包含全部目标字段，且抽样验证满足业务要求时才适合。JSON-LD 可能缺少字段，也可能不反映实时价格、库存或页面状态。

应该优先选择浏览器自动化吗？

通常不应该。原始 HTML 已包含完整 JSON 时，直接解析更快且资源成本更低；只有数据依赖脚本执行、登录或交互时，才应考虑浏览器自动化。

可以用正则表达式提取 script 中的 JSON 吗？

不建议作为通用方案。应先使用 HTML 解析器定位 script 节点，再用 JSON 解析器处理节点文本，以降低嵌套结构、转义字符和页面变化造成的错误。

接口返回 JSON，是否一定比解析 HTML 更稳定？

不一定。公开且有版本说明的 API 通常较稳定，但网页内部接口可能依赖动态参数、Cookie 或令牌，也可能随前端版本变化。

总结

网页内嵌 JSON 是放在 HTML 文档或页面运行环境中的结构化数据。选型时先确认数据位置：原始 HTML 有完整 JSON 就直接解析；数据依赖脚本、登录或交互时使用浏览器自动化；数据由独立接口返回且允许直接访问时请求接口。多种方案都可行时，优先选择字段完整、运行成本低、变化可监测且符合访问规则的实现。