2026 年用于网络抓取的 Python 无头浏览器库

无头浏览器本质上就是一款普通的网页浏览器（如 Chrome、Firefox 或 WebKit），只是其图形用户界面（GUI）被关闭了。它依然会解析 HTML、执行 JavaScript、触发 DOMContentLoaded、运行单页应用的 React 树，并允许你点击按钮、在输入框中输入内容或截取屏幕截图。区别在于没有任何内容会绘制到屏幕上，这使得它在服务器、容器或持续集成（CI）任务中运行成本极低。

值得将人们常混为一谈的三个层级进行区分：

• HTTP 客户端（如 requests 和 httpx：快速、轻量，但不运行 JavaScript。如果所需数据包含在初始 HTML 中，这就是合适的工具。
• HTML 解析器（如 BeautifulSoup、Parsel 或 lxml）：它们处理你获取的任何 HTML 并允许你对其进行查询。它们既不负责获取数据，也不负责渲染。
• 无头浏览器：可通过代码驱动的完整浏览器引擎。它们会渲染页面、执行 JavaScript，并提供可供查询和交互的 DOM。

当你选择 Python 无头浏览器时，你所获得的是一项特定能力：一个具备真实 DOM 的 JavaScript 运行时环境。其他一切，包括内存开销和延迟，都是这一选择的必然结果。如果你是该领域的新手，了解浏览器自动化的基础知识将是一个有用的下一步。

大多数团队都会忽略的坦率答案是：你可能并没有想象中那么频繁地需要 Python 无头浏览器。为每个请求启动 Chromium 是获取网页成本最高的方式，而且许多“JavaScript 渲染”的网站其实会通过 JSON 接口默默地暴露相同的数据， requests 。

在以下情况下请使用无头浏览器：

• 您所需的数据是在页面加载后由客户端 JavaScript（React、Vue、Svelte、Angular 单页应用）注入的。
• 流程需要真实的交互操作：点击“加载更多”按钮、滚动无限滚动内容、悬停以显示菜单，或完成多步骤登录。
• 您需要对渲染后的页面进行截图、生成 PDF 或录制视频。
• 该网站会积极检测客户端指纹，并拒绝任何非真实浏览器 TLS 握手请求。

当页面是服务器渲染的 HTML、背后存在已文档化或可发现的 API，或是访问静态页面的站点地图时，请跳过浏览器。请求客户端加解析器的方案将快 10 到 50 倍，成本更低，且扩展性无限。仅在页面确实需要时才使用最繁重的工具。

Selenium 自 2004 年问世以来，至今仍是 Python 无头浏览器领域兼容性最广的选择。它通过 WebDriver 与 Chrome、Firefox、Edge 和 Safari 通信，几乎支持所有编程语言的绑定，并受益于二十年来 Stack Overflow 上的海量解答。如果您正在维护现有的测试套件，或在多语言团队中工作，Selenium 通常是阻力最小的路径。

Selenium 4 极大地简化了安装流程。Selenium Manager 随库一同发布，并能自动识别正确的驱动程序二进制文件，因此手动下载 chromedriver.exe 并匹配版本的日子已基本成为历史。若想深入了解，官方 Selenium 文档是权威参考。一个最简的无头 Chrome 脚本如下所示：

from selenium import webdriver
from selenium.webdriver.chrome.options import Options
from selenium.webdriver.common.by import By

options = Options()
options.add_argument('--headless=new')
options.add_argument('--no-sandbox')

driver = webdriver.Chrome(options=options)
try:
    driver.get('https://example.com')
    title = driver.title
    heading = driver.find_element(By.TAG_NAME, 'h1').text
    driver.save_screenshot('example.png')
    print(title, heading)
finally:
    driver.quit()

优点：广泛的浏览器支持、庞大的社区、成熟的分布式运行网格、最知名的跨语言 API。缺点：默认同步的 API、没有内置的自动等待功能（你需要编写大量 WebDriverWait），且原生 Selenium 极易被识别为自动化工具。

在反机器人方面，生态系统填补了这一空白。 selenium-stealth 弥补了最明显的 navigator.webdriver 和 WebGL 特征，而 undetected-chromedriver 是一个即插即用的替代方案，多年来一直是针对受Cloudflare保护的目标的首选。虽然两者都不是对抗现代指纹识别堆栈的万能解，但都仍是有效的首道防线。如果您的项目专门针对Cloudflare，我们的《Cloudflare绕过指南》将更详细地介绍实用的模式。

在 2026 年，对于新的 Python 无头浏览器项目而言，Playwright 堪称最接近默认推荐的选择。它由微软维护，提供官方支持的 Python 绑定（请参阅 Playwright Python 文档了解当前的安装矩阵），并在 Chromium、Firefox 和 WebKit 平台上提供统一的 API。 通信通过持久的 WebSocket 连接进行，而非 Selenium 所使用的频繁往返的 HTTP 请求，这正是其在基准测试中往往显得更敏捷的重要原因之一。

安装只需两条命令：

pip install playwright
playwright install

第一条命令安装 Python 包；第二条命令将修补后的浏览器二进制文件下载到 Playwright 管理的缓存中。以下是一个最简异步示例，用于加载页面、等待内容加载并获取全屏截图：

import asyncio
from playwright.async_api import async_playwright

async def run():
    async with async_playwright() as p:
        browser = await p.chromium.launch(headless=True)
        context = await browser.new_context(
            user_agent='Mozilla/5.0 (X11; Linux x86_64) ...',
            locale='en-US',
        )
        page = await context.new_page()
        await page.goto('https://example.com', wait_until='networkidle')
        title = await page.title()
        await page.screenshot(path='example.png', full_page=True)
        print(title)
        await browser.close()

asyncio.run(run())

有三个 Playwright 功能值得重点介绍，因为它们直接解决了导致 Selenium 使用体验不佳的问题：

• 自动等待。 page.click() 以及 page.fill() 在触发操作前，会等待元素加载完成、可见且可交互。这样您需要编写的等待代码更少，脚本的稳定性也更高。
• 浏览器上下文。单个浏览器进程可托管多个隔离的上下文，每个上下文拥有独立的 Cookie、存储和代理。这是实现独立会话并行抓取的理想基础。
• 跟踪查看器。 context.tracing.start(screenshots=True, snapshots=True) 会完整记录网络请求、DOM 快照和控制台输出的时间线，供您后续查阅。它将“昨天生产环境中的抓取失败”从一种猜测游戏转变为一次调试会话。

如果你今天要启动一个新的 Python 无头浏览器项目，除非有特殊原因，否则请默认使用 Playwright。我们的《Playwright 网络爬虫深度指南》详细介绍了生产环境中的选择器、定位器和路由机制。

Pyppeteer 是 Node.js 的 Puppeteer（谷歌原生 Chrome DevTools 协议库）的非官方 Python 移植版。其 API 几乎与 Puppeteer 完全一致，这对于移植 Node 教程中的代码片段非常方便，且其异步设计对于短暂的并发任务确实高效。 根据原始资料中的基准测试，在处理非常短的脚本时，Pyppeteer 的运行速度比 Playwright 快约 30%，不过我们建议将其视为参考，而非绝对标准。

2026年的诚实提醒：Pyppeteer的上游维护已显滞后。它仅支持Chromium，无法追踪当前的Puppeteer/Chromium版本，且GitHub问题跟踪器显示该项目更多依赖社区善意而非积极管理（采用前请先核实Pyppeteer仓库的当前提交频率）。 对于新代码，Playwright 拥有更活跃的代码库，且能覆盖相同的使用场景。一个可运行的代码片段仍如下所示：

import asyncio
from pyppeteer import launch

async def main():
    browser = await launch(headless=True, args=['--no-sandbox'])
    page = await browser.newPage()
    await page.goto('https://example.com', {'waitUntil': 'networkidle0'})
    await page.screenshot({'path': 'example.png', 'fullPage': True})
    print(await page.title())
    await browser.close()

asyncio.run(main())

若您已有不愿重写的 Pyppeteer 代码库，或特别需要其 CDP 风格的 API，请使用 Pyppeteer。否则，Playwright 是更稳妥的选择。我们的 Pyppeteer 长篇指南将深入探讨其仍值得使用的场景。

Splash 则是个特例：它不将浏览器运行在 Python 进程内部，而是让你将 Splash 本身作为 Docker 容器运行，该容器会暴露一个 HTTP API。你向其发送一个 URL，它便会启动一个基于 WebKit 的渲染器，执行 JavaScript 代码，并返回渲染后的 HTML、截图，或是你的 Lua 脚本计算出的任何结果。它通过 scrapy-splash 中间件与 Scrapy 配合得尤为默契。

启动本地 Splash 服务器只需一条命令：

docker run -p 8050:8050 scrapinghub/splash

在 Python 中，您可通过纯文本 requests:

import requests

params = {'url': 'https://example.com', 'wait': 2, 'timeout': 30}
r = requests.get('http://localhost:8050/render.html', params=params, timeout=60)
html = r.text

优点：进程隔离（有漏洞的页面无法导致爬虫崩溃）、简单的 HTTP 接口，以及支持通过 Lua 脚本实现自定义渲染流程。缺点：WebKit 并不总是能完美适配仅针对 Chrome 进行测试的网站，项目进展缓慢，且现代反机器人系统经常会将 Splash 的指纹标记为可疑。 大多数新项目会选择 Playwright 或托管 API，但如果你已经拥有 Scrapy 管道，Splash 仍是将其与 JavaScript 渲染无缝集成的便捷方案。我们的 Scrapy 和 Splash 教程展示了端到端的集成过程。

到了某个阶段，运行自己的 Python 无头浏览器集群将不再令人愉快。反机器人供应商每周更新指纹库，住宅代理需要轮换逻辑，而 Chromium 在容器中的内存占用会迅速倍增。托管浏览器 API 通过提供远程浏览器来解决这些问题，您可以通过 HTTP 或兼容 Playwright/Selenium 的 WebSocket 端点来控制它。

从代码角度看，它们在概念上都大同小异。以下是一个通过 Playwright 连接托管服务的通用示例：

from playwright.sync_api import sync_playwright

WS_ENDPOINT = 'wss://browser.example.com?token=YOUR_API_KEY'

with sync_playwright() as p:
    browser = p.chromium.connect_over_cdp(WS_ENDPOINT)
    context = browser.contexts[0]
    page = context.new_page()
    page.goto('https://target.example.com')
    print(page.title())
    browser.close()

您通常能获得：托管 Chromium 浏览器集群、内置住宅或移动代理、自动 CAPTCHA 处理、指纹随机化以及按请求的会话控制。您需要放弃的：网络跳转带来的轻微延迟、按请求计费，以及对浏览器二进制文件的精细控制。

当出现以下三种情况之一时，便是切换的合适时机：您开始在高价值目标上遭遇持续性的访问阻断；运行 Chromium 产生的 AWS 账单远超 API 订阅费用；或者您的团队根本不想涉足浏览器运维业务。WebScrapingAPI 提供的浏览器 API 是该类别中的一个选项，而且如今托管浏览器领域已足够成熟，日后更换服务商通常只需更改凭据即可。

尽管以下几款轻量级工具并未与 Selenium 和 Playwright 直接竞争，但仍值得一提。

• Requests-HTML。这是一个围绕 requests 和 Pyppeteer 的封装工具，允许您仅在需要时启用 JavaScript 渲染。安装需 pip install requests-html (Python 3.6+)；首次调用 .render() 会将 Chromium（约 150 MB）下载到 ~/.pyppeteer/。对于大多数页面为静态的一次性抓取非常实用。
• MechanicalSoup。这完全不是无头浏览器，而只是基于 BeautifulSoup 的带状态 HTTP 客户端，能够处理表单和 Cookie。适用于老式的服务器端渲染网站、不依赖 JavaScript 的登录流程，或填写经典的 HTML 表单。使用 pip install mechanicalsoup.
• nodriver 安装。这是 undetected-chromedriver 的继任者，出自同一位作者之手。它完全摒弃了 WebDriver 层，转而通过 CDP 直接与 Chrome 通信，这使得其更难被识别为自动化工具。虽然它还比较新，但许多反检测社区的开发者已纷纷转向它。

虽然这些工具无法完全替代完整的 Python 无头浏览器栈，但各自都填补了特定的细分领域。

以下是速查表。请将“反机器人”一栏视为相对排名，而非绝对分数：任何库都可能被有针对性的指纹识别工具检测到，而任何库在搭配合适的插件后都能通过常规检测。

请将此表作为初步筛选依据，然后深入查看上方对应部分，找到符合您条件的库。

对任何单一的 Python 无头浏览器基准测试结果都应持保留态度：结果会因目标页面、网络状况、主机环境以及浏览器是冷启动还是重用而波动。下方的数据摘自我们构建此比较时所参考的公开基准测试资料，我们已将其标记为近似值，因为在撰写本文时我们尚未独立重跑这些测试。

短脚本计时。在一项已发表的对比中，面对相同的工作负载，Playwright 约 290 毫秒内完成了大约 100 次迭代，而 Selenium 则耗时约 536 毫秒，这与 Playwright 在 WebSocket 传输方面的优势相符。据报告，在非常短的脚本中，Pyppeteer 的运行速度比 Playwright 快约 30%，这可能是因为它跳过了 Playwright 的自动等待和协议开销。

截图基准测试。另一项并行测试报告的近似端到端耗时如下：

• Selenium：约 3.15 秒
• Playwright：约 3.94 秒（全屏截图）
• Pyppeteer：约 4.12 秒
• Splash：约 4.25–6.04 秒，平均约 4.78 秒

Selenium 在此处的优势部分源于测试仅捕获了视口截图，而非全页面渲染。

实际启示。在单台机器上进行稳态每分钟页面测试时，Playwright 和 Selenium 的性能处于同一数量级；二者之间的差异很少会主导你的吞吐量。真正起决定性作用的是并发策略（浏览器池、上下文或进程）以及每个页面等待网络和 JS 响应所花费的时间。如果你要进行认真的优化，请在实际的目标页面和硬件上运行你自己的基准测试。

如果目标网站使用了 Cloudflare、DataDome、PerimeterX 或任何现代反机器人管理方案，任何 Python 无头浏览器的默认安装版本都会在发送几个请求后就被标记。可被指纹识别的特征面非常广泛： navigator.webdriver，包括缺失的插件、WebGL参数、Chromium构建版本的TLS/JA3签名，甚至HTTP/2帧的顺序。以下是各库实际提供的功能：

• Selenium. selenium-stealth 修补了最明显的 JavaScript 特征。 undetected-chromedriver 而较新的 nodriver 则更进一步，直接替换了驱动层本身。但这些方案均未改变您的 TLS 指纹，而这正日益成为最薄弱的环节。
• Playwright. playwright-stealth （ puppeteer-extra-plugin-stealth) 负责处理 JavaScript 侧的检测。浏览器上下文（Browser contexts）让你能干净利落地轮换身份，而基于路由的处理程序（per-route handlers）则允许你在无需重启浏览器的情况下注入自定义头部和 Cookie。
• Pyppeteer。隐身工具功能有限，且其改进滞后于上游的 Puppeteer。
• Splash。几乎没有任何隐身功能。它基于 WebKit 而非 Chrome，现代指纹识别工具能迅速识别这一点。
• 托管浏览器 API。这正是其价值所在。真实的住宅或移动 IP、跨浏览器版本的指纹轮换、托管的验证码破解，以及与零售版浏览器匹配的 TLS 配置文件。当目标受到真正防御时，这通常是唯一现实的选择。

实用经验法则：隐身插件配合干净的住宅代理足以突破常规防护。面对强力反机器人系统，你需要一个完整的 Python 无头浏览器指纹，它必须模拟真实住宅 IP 上的真实 Chrome 浏览器，而这通常需要托管浏览器。添加住宅代理实现 IP 轮换可解决网络层问题；浏览器层的问题则由隐身工具和托管 API 来解决。

一旦不再局限于逐页处理，您的 Python 无头浏览器策略将从“选用哪个库”转变为“采用哪种并发模型”。以下三种模式可覆盖绝大多数场景：

1. 单浏览器多上下文（Playwright）。成本最低且速度最快。每个上下文在 Cookie、存储和代理方面相互隔离，但共享浏览器进程。
2. 多个浏览器实例。隔离性更强，内存消耗更大。当上下文之间存在状态泄漏，或需要使用不同浏览器构建版本时，可采用此方案。
3. 多进程（Selenium）。Selenium 的同步 API 难以实现资源共享，因此通常需在 concurrent.futures.ProcessPoolExecutor 或通过 Selenium Grid 跨机器运行 N 个驱动程序。

使用上下文和 asyncio.gather:

import asyncio
from playwright.async_api import async_playwright

URLS = ['https://example.com/p/{}'.format(i) for i in range(20)]

async def fetch(browser, url):
    ctx = await browser.new_context()
    page = await ctx.new_page()
    try:
        await page.goto(url, wait_until='domcontentloaded', timeout=30000)
        return await page.title()
    finally:
        await ctx.close()

async def main():
    async with async_playwright() as p:
        browser = await p.chromium.launch(headless=True)
        sem = asyncio.Semaphore(5)  # cap concurrency
        async def bound(u):
            async with sem:
                return await fetch(browser, u)
        results = await asyncio.gather(*(bound(u) for u in URLS))
        await browser.close()
        print(results)

asyncio.run(main())

Cap并发机制，配合信号量实现的简约Playwright扇出方案，需注意内存管理并定期回收浏览器。Chromium在数千次加载过程中，每加载一页会泄漏少量内存。

本地环境尚可；但在生产环境中，Chromium 会表现出强烈的“个性”。两条能最大程度避免麻烦的运维准则：部署经过验证的基准镜像，并锁定浏览器版本。

一个用于 Playwright 任务的简易 Dockerfile 示例：

FROM mcr.microsoft.com/playwright/python:v1.47.0-jammy
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "scrape.py"]

官方 Playwright 镜像已预装浏览器，以及 Chromium 所需的系统字体、编解码器和共享库。Selenium 对应的组件是 selenium/standalone-chrome 镜像。

GitHub Actions。使用 microsoft/playwright-github-action (或直接使用 pip install playwright && playwright install --with-deps) 并设置 headless=True。通过哈希您的 requirements.txt ，以确保 CI 运行速度快。

AWS Lambda。完整的 Chromium 对于 Lambda 的 zip 文件来说体积过大。请使用包含 chromium-headless-shell，或在 Fargate/ECS 上运行，这些环境对 10 GB 的镜像限制更为宽松。完整 Chromium 的冷启动时间通常超过 2 秒，因此 Lambda 最适合低流量、对延迟不敏感的任务。

始终在 --no-sandbox 仅在沙箱容器内运行，切勿在主机上运行。

跳过理论探讨，直接参考分支。本决策树涵盖了大多数团队在采用 Python 无头浏览器时实际面临的场景。

• 静态或服务器渲染的页面，无需 JS。根本无需使用浏览器。使用 requests 或 httpx 配合 BeautifulSoup 或 Parsel。
• 对JS密集型SPA进行中小规模抓取，且无强力反机器人措施。使用Playwright。现代API、官方Python支持、开箱即用的异步功能。结论：Playwright。
• 现有 Selenium 代码库，或团队成员均熟悉 Selenium 的多语言开发团队。继续使用 Selenium 4 配合 Selenium Manager。不要为了迁移而迁移。结论：Selenium。
• 登录流程、多步骤表单或双因素认证（2FA）。可选用 Playwright（配合 storage_state 实现会话复用）或 Selenium 配合显式等待。结论：推荐 Playwright。
• Cloudflare、DataDome 或 PerimeterX 构成阻碍。优先使用 Stealth 插件配合住宅代理；若失败，则转用托管浏览器 API。结论：托管浏览器。
• 现有 Scrapy 管道，仅需轻量级 JS 渲染。通过 scrapy-splash 仍是阻力最小的路径。结论：Splash。
• 每日数百万页面，目标类型混合。受保护的目标使用托管浏览器 API，其余使用原生 HTTP。结论：混合方案。

大多数 Python 无头浏览器错误都集中在以下几种常见错误上：

• 未显式设置等待。 time.sleep(2) 并非等待策略。请使用 Playwright 的自动等待功能，或 Selenium 的 WebDriverWait 并配合显式条件。
• 浏览器进程泄漏。务必在 finally 块中 async with中关闭浏览器。一个运行时间过长且忘记 quit() 的爬虫将在数小时内耗尽内存。
• 默认用户代理。无头版Chrome会在其用户代理字符串中暴露自身身份。请将其覆盖为最新稳定版Chrome的值。
• 重复使用单一上下文。第 1 页的 Cookie 和存储数据会跟随你到第 100 页。当会话管理至关重要时，请为每次会话使用全新的上下文。
• Docker 中缺少系统字体。页面虽“正确”渲染，但文字尺寸不符且基于 CSS 的布局检测失效。请安装 fonts-liberation 并 fonts-noto-color-emoji 。

当出现问题时，请在失败时截屏、保存渲染后的 HTML，并开启 Playwright 的跟踪查看器。大多数不稳定的抓取工具在获得真实的时间线供分析后，通常会在一小时内停止出现异常。

• 编写新的 Python 无头浏览器代码时，请优先选用 Playwright。其异步 API、官方 Python 支持、自动等待、浏览器上下文以及跟踪查看器，消除了导致 Selenium 使用体验糟糕的诸多缺陷。
• 若您拥有现有代码库、多语言开发团队，或需要最广泛的浏览器支持，Selenium 依然是不错的选择。Selenium 4 配合 Selenium Manager 可消除安装困扰。
• Pyppeteer 和 Splash 虽属小众，但并未过时。Pyppeteer 适用于转换 Puppeteer 代码片段，Splash 适用于现有的 Scrapy 管道。但不要在全新项目中选用它们。
• 当反机器人防御、规模或运维成本不再值得投入工程时间时，请切换到托管式浏览器 API。集成工作主要只需更改凭据。
• 请针对您的具体目标进行基准测试。公开的基准数据仅是方向性参考，而非硬性标准。冷启动、页面加载量和并发模型对结果的影响远大于库的选择。

对于全新的 Python 无头爬取项目，Playwright 通常是更优的首选。它自带官方支持的 Python 绑定、原生异步 API、操作自动等待、用于并行会话的浏览器上下文，以及用于调试的跟踪查看器。Selenium 在浏览器兼容性、生态系统成熟度以及现有测试基础设施方面更具优势。新建项目请选用 Playwright，已有成熟技术栈时则选用 Selenium。

Pyppeteer 由社区维护，其版本通常滞后于上游的 Puppeteer 和 Chromium 发布。它仍适用于简短的异步脚本，但对于新项目，Playwright 不仅能满足相同的使用场景，还具备积极的维护、更好的跨浏览器支持以及更丰富的 API。如果您有现成的代码库且不想迁移，请继续使用 Pyppeteer；否则，建议默认选用 Playwright。

在某些情况下，借助辅助工具可以。像 selenium-stealth, undetected-chromedriver, nodriver和 playwright-stealth 等隐身插件可修补最明显的 JavaScript 特征，而优质的住宅代理则负责 IP 地址管理。面对激进的 Cloudflare 或 DataDome 配置时，仅靠这些通常不够，因为 TLS 和 HTTP/2 指纹也会泄露自动化行为。此时，托管浏览器服务才是切实可行的备选方案。

当出现以下三种情况之一时，就该转换：你在高价值目标上持续被封锁、Chromium 浏览器集群的基础设施成本超过 API 订阅费用，或者你的团队不愿负责浏览器运维。托管服务集成了住宅代理、指纹轮换和 CAPTCHA 处理功能，将数周的规避工程工作简化为一次凭证更新。

使用已预装浏览器的基础镜像，例如 mcr.microsoft.com/playwright/python 或 selenium/standalone-chrome。在容器内部，使用 headless=True 并 --no-sandbox （容器本身已处于沙箱环境中）。对于 GitHub Actions，请使用 playwright install --with-deps 安装浏览器，并根据您的锁定文件缓存二进制目录，以确保 CI 运行速度快。

选择合适的 Python 无头浏览器归根结底取决于三个关键问题：页面实际需要多少 JavaScript 支持、目标系统的防护强度如何，以及你愿意承担多少运维复杂度。对于新代码，建议默认使用 Playwright；若已有成熟的技术栈，则继续使用 Selenium；将 Pyppeteer 和 Splash 视为特定场景的利器；当隐蔽性和扩展性开始占用你的周末时间时，不妨考虑托管浏览器。 上方的决策树将大多数实际场景映射为一行结论，而对比表则能在您需要重新评估选择时提供快速筛选依据。

若您发现自行维护 Chromium 浏览器集群已不值得投入精力，WebScrapingAPI 提供的浏览器 API 可为您提供一个易于 Python 调用的托管式无头端点，内置住宅代理、指纹轮换及 CAPTCHA 处理功能，让您的代码保持不变，同时将反机器人工作从您的肩上卸下。 无论您选择哪种方案，都请在真实目标环境中进行性能测试，从第一天起就为生产环境做好规划，并且在 JSON 接口足以满足需求时，请勿使用浏览器。