Playwright+TypeScript实现API级数据采集：绕过反爬的完整方案

最近在重构一个数据采集项目的时候我又把老路子彻底推翻了一遍。以前碰到需要稳定拿数据的站点第一反应就是用 Requests 或 Node 的 fetch 直接怼接口然后被签名、加密参数、风控策略一顿毒打。后来切到Playwright TypeScript这套组合直接用浏览器帮我们完成“人机验证、登录态管理、参数生成”再从浏览器网络层把接口响应原样接出来数据干净、结构清晰、维护成本低。这篇文章就把我这套方案完整拆给你看适合正在做 API 级数据采集、接口数据分析、以及想把 Playwright 从“自动化测试工具”改造成“数据采集利器”的朋友。1. 为什么我放弃了纯 HTTP 库转用 Playwright 做 API 级采集1.1 纯 HTTP 方案遇到的三个无解问题我早期的爬虫核心逻辑特别朴素打开浏览器的开发者工具找到 XHR 请求复制 URL、Header、Payload然后丢到 Python 或 Node 里重放。这个套路在早期好使但现在越来越难用核心是三个问题第一登录态和动态签名变得越来越复杂。很多站点的接口不是简单带个 Cookie 就能过的它们会在请求头里塞X-Sign、X-Timestamp、Device-Id甚至某些参数是经过本地加密算法生成的可能还依赖 WebCrypto、WASM 之类的东西。你要是纯手工逆向这些算法工作量会非常恐怖而且站点一旦升级加密逻辑你的脚本基本就废了。第二验证码和风控策略无法绕过。滑块验证、点选验证、无感验证这些基本都是“行为验证 设备指纹 频率风控”的组合拳。你用 Python 去模拟滑块的轨迹即使算出了正确的缺口位置轨迹不够拟人照样被识别。Playwright 给我带来的最大价值就是让浏览器自己处理这些验证环节脚本只负责等待结果和采集结果。第三纯 HTTP 无法应对前端加密的参数拼接逻辑。比如登录时要把密码做两次 RSA 加密后再传给后端这种逻辑通常写在一个压缩过的 js 文件里人工逆向成本极高。而浏览器自己就会执行这段 JS我们在它执行完之后轻松从网络层把最终请求和响应拦截出来等于绕过了“逆向参数生成过程”直接拿到最终产物。1.2 Playwright 解决的其实不是“渲染”而是“环境信任”我知道很多人提到 Playwright第一反应是“无头浏览器渲染动态页面”。这个理解没有错但它忽略了更关键的一点Playwright 让你拥有了一个和真实用户几乎完全一致的浏览器环境。这个环境里包含了完整的浏览器指纹、TLS 指纹、字体列表、Canvas 渲染特征、WebGL 信息还有正常用户访问时才会生成的 Cookie、LocalStorage、IndexedDB 等状态。当你用这个环境去请求 API 时服务端看到的是一台真实设备而不是一个来自 Python Requests 库的“可疑客户端”。我在操作中把它拆成三层来用渲染层负责打开页面、触发事件、等待 Ajax 加载完成。网络层通过事件监听拿到所有请求和响应筛选目标 API。执行层通过page.evaluate在页面上下文里执行 fetch、调用全局函数甚至读取内存里缓存的加密密钥。这三层揉在一起让 Playwright 不仅能“看页面”还能“调接口”而且活得有点像浏览器内部的调试器。这也是它比 Selenium 更适合做数据采集的原因Selenium 也能控制浏览器但网络层监听和请求拦截能力远没有 Playwright 这套 API 设计得顺手。1.3 这套方案适合谁不适合谁我从实际项目里总结了一下这套方案的适用边界大概是这样场景推荐程度原因前后端分离的 SPA 站点数据采集非常推荐接口数据往往是 JSON结构化程度高拦截后几乎零解析成本需要稳定保持登录态的采集任务非常推荐storageState 可以把登录态落盘随时复用需要处理动态签名、加密参数的接口比较推荐免去逆向 JS浏览器自己算好参数低频小批量的竞品监测、报表汇总很推荐开发快维护简单超大规模分布式采集不太推荐浏览器实例重内存开销远高于纯 HTTP量大了成本高目标网站有明确的数据导出 API 或官方 SDK不推荐没必要绕一圈官方接口才是正路一句话总结当你需要“像人一样访问”才能拿到数据时Playwright 是最好的入场券当目标接口完全开放、纯 HTTP 能跑通时别给自己找麻烦。2. 项目初始化与环境准备TypeScript Playwright2.1 Node.js 环境与项目初始化这套方案我选TypeScript而非纯 JavaScript主要看中的是类型安全。拦截到的响应体、请求头、存储状态这些数据结构在 TS 里定义好 interface 以后写起来不仅补全友好字段名错了还能在编译期直接报错避免数据采集中最常见的“字段名写错导致长时间跑脏数据”的问题。先用 Node.js 18 以上的版本直接初始化项目mkdir api-crawler cd api-crawler npm init -y npm install typescript tsx types/node -D npm install playwright这里我把tsx装上了它的作用是直接运行 TypeScript 文件不需要先编译再跑调试的时候非常方便。然后初始化 TS 配置npx tsc --inittsconfig.json里把target改成ES2022module改成ESNextstrict打开。实际跑脚本时我一般不会用tsc编译而是直接用tsx运行npx tsx src/index.ts2.2 Playwright 浏览器内核安装装完 Playwright 库之后还需要单独下载浏览器内核这个坑很多新手容易漏掉npx playwright install chromium默认情况下 Playwright 使用它自己维护的 Chromium 内核。如果你本机已经有 Chrome 或 Edge也可以让 Playwright 直接连接系统浏览器import { chromium } from playwright; const browser await chromium.launch({ headless: false, channel: chrome, });用channel: chrome的好处是在某些只认证 Google Chrome 指纹的站点里成功率比默认 Chromium 更高。坏处是如果你本机 Chrome 经常自动升级可能会遇到版本不匹配的报错。我自己的建议是默认先用 Playwright 内置 Chromium遇到指纹问题再切系统浏览器没必要一开始就增加环境依赖。2.3 使用 Codegen 快速抓取登录流程选择器如果你不知道目标站点的登录按钮、输入框选择器长什么样手动翻 HTML 太累。Playwright 自带一个 Codegen 工具能在你手动操作浏览器的同时自动录制选择器npx playwright codegen https://example.com/login录制完你会得到一段包含click、fill、waitForSelector等操作的脚本我在实际操作中一般不会直接照搬而是把它当作“选择器字典”来用。比如登录按钮是button[typesubmit]还是#login-btn录一次就有答案了。在写正式采集脚本前我建议先用 Codegen 把登录流程脚本录出来然后删掉其中和采集无关的操作只保留登录核心步骤这样登录部分的稳定性会高很多。3. 核心实现拦截浏览器流量把 API 响应变成数据源3.1 监听 response 事件结构化拿数据Playwright 里最实用的一个 API 就是page.on(response)。它能监听到页面上所有网络请求的响应包括 XHR、Fetch、文档、图片、脚本等。我通常在事件回调里做四个判断请求资源类型是不是xhr或fetch。URL 是否符合目标接口规则。响应状态码是否为 200。响应内容能否被解析成 JSON。完整示例import { chromium } from playwright; interface ProductItem { id: number; name: string; price: number; } const browser await chromium.launch({ headless: true }); const page await browser.newPage(); const apiResponses: ProductItem[] []; page.on(response, async (response) { const url response.url(); const resourceType response.request().resourceType(); if (resourceType ! xhr resourceType ! fetch) return; if (!url.includes(/api/product/list)) return; if (!response.ok()) return; try { const data await response.json(); if (data?.data?.list) { apiResponses.push(...data.data.list); } } catch (err) { // 非 JSON 响应直接跳过 } }); await page.goto(https://example.com/products, { waitUntil: networkidle }); console.log(采集到 ${apiResponses.length} 条商品数据); await browser.close();注意response.json()只能调用一次因为响应体在 Playwright 的设计里是流式的调用了之后就没了。如果既想拿 JSON又想拿原始文本最好只用response.text()然后自己 JSON.parse灵活性最高。3.2 另一种思路在页面上下文里直接 fetch 接口监听response的方式适合“页面本身会调用接口”的场景。但也有一种情况页面只在某些条件下才会加载某类数据或者需要在页面里先处理参数再请求接口。这时候我会直接在浏览器页面的上下文里执行 fetch让浏览器自己带上 Cookie、加上签名然后把结果返回给 Node 进程。const data await page.evaluate(async (productId) { const resp await fetch(/api/product/detail?id${productId}, { method: GET, headers: { Accept: application/json, }, }); return await resp.json(); }, 1024); console.log(data);使用page.evaluate有几点经验evaluate回调里不能直接引用外部变量必须通过第二个参数传进去。上述代码里productId就是从外部传入的。页面里的 fetch 会自动携带当前域的 Cookie所以能直接复用登录态。如果你的回调里要用await外层回调必须声明为asyncPlaywright 会等待 Promise resolve 后再返回结果。这种方式最大的优势就是你的请求用的是一等一真实浏览器的加密逻辑和身份凭证无需逆向。缺点是不能像监听response那样精确控制“当页面自己发请求时”的时机所以在实际项目里我会把两种方式结合页面自动请求用监听手动查询接口用 evaluate。3.3 资源过滤关掉图片、字体、CSS只留接口请求很多采集场景下我们要的只是接口数据不需要浏览器真的把图片、字体、样式全都下载下来。这会浪费带宽甚至会被目标站点的 CDN 限速。Playwright 提供了route接口可以拦截并中止非必要请求await page.route(**/*, (route, request) { const resourceType request.resourceType(); const url request.url(); if ([image, media, font, stylesheet].includes(resourceType)) { route.abort(); } else if (url.includes(/api/)) { route.continue(); } else { route.continue(); } });这段配置跑下来页面上的图片、视频、字体全部不会加载请求量经常能减少 70% 以上。但这里有个注意事项如果目标站点的 API 接口校验了 Referer或者某些数据要通过图片懒加载触发粗暴地拦截图片会导致页面逻辑异常。我的习惯是先跑一次全量请求在控制台看哪些资源是真正影响接口调用的再逐步过滤。不要一上来就把所有静态资源全 block 了否则可能连 JS 文件都被拦掉页面直接白屏接口也不会触发。3.4 等待策略与超时熔断用 Playwright 采集时最让人头痛的是页面加载速度不稳定。网络慢的时候接口迟迟不返回页面异常时可能有报错弹窗挡住操作。我的等待策略主要分三种用page.waitForResponse精准等待目标接口。这是我最常用的方式比waitForTimeout好用且快得多。const [response] await Promise.all([ page.waitForResponse((resp) resp.url().includes(/api/product/list)), page.click(.load-more-btn), ]); const data await response.json();顺带解释一下Promise.all的作用先点击按钮再等接口会有竞态风险——万一接口在 click 的异步处理中已经返回了等你调用waitForResponse时可能已经错过了。所以应该同时发起“点击”和“等待响应”两个异步动作。当页面要发多个接口时我会写一个等待函数轮询检查结果是否齐全并用超时兜底。const deadline Date.now() 15000; while (Date.now() deadline) { if (apiResponses.length expectedCount) break; await page.waitForTimeout(200); } if (apiResponses.length expectedCount) { console.warn(超时只采集到 ${apiResponses.length} 条数据); }核心操作全部设置超时比如page.goto(url, { timeout: 30000 })避免某个页面卡死拖慢整个采集进程。4. 工程化落地登录态复用、并发控制与输出4.1 storageState登录一次长期复用这是整套方案里我个人认为含金量最高的环节。用 Playwright 登录目标站点后浏览器里攒下了一堆 Cookie、LocalStorage、IndexedDB 数据。如果每次跑脚本都要重新登录效率非常低还容易被风控盯上。Playwright 原生支持把浏览器状态保存成文件import { chromium } from playwright; const browser await chromium.launch({ headless: false }); const context await browser.newContext(); const page await context.newPage(); // 手动或自动登录 await page.goto(https://example.com/login); await page.fill(#username, your_account); await page.fill(#password, your_password); await page.click(button[typesubmit]); await page.waitForSelector(.user-info); // 保存登录态 await context.storageState({ path: auth-state.json }); await browser.close();之后再启动采集任务时直接加载这个状态文件const context await browser.newContext({ storageState: auth-state.json, }); const page await context.newPage(); // 直接访问需要登录的页面无需重新登录关于 storageState 我有三个实际经验登录态不是永久的。很多站点服务端 session 有有效期一般 1 到 7 天不等。我会写一个检查函数每次启动时先访问一个需要鉴权的接口如果返回 401 就重新登录。storageState只保存 Cookie、LocalStorage、IndexedDB 等状态不会保存内存中变量。如果目标站点用了内存缓存来校验登录状态重新加载后可能失效。不要把 auth-state.json 提交到 Git 仓库里面包含敏感凭证。建议在.gitignore里加上。4.2 并发控制不要一次性开 50 个浏览器采集任务量大时很多人会下意识地把任务并发起来。Playwright 支持多浏览器实例、多页面并发但对系统资源的占用非常惊人。一个 Chromium 实例的内存通常在 200MB 到 500MB 之间开 10 个基本就能拖垮一台普通开发机。我的做法是在单浏览器实例内开多个 context 或页面用并发池控制同时运行的 Task 数量。这里用p-limit这个库代码简单清晰npm install p-limitimport pLimit from p-limit; import { chromium } from playwright; const browser await chromium.launch({ headless: true }); const limit pLimit(3); const tasks productIds.map((id) limit(async () { const context await browser.newContext({ storageState: auth-state.json }); const page await context.newPage(); try { const data await page.evaluate(async (pid) { const resp await fetch(/api/product/detail?id${pid}); return await resp.json(); }, id); results.push(data); } finally { await context.close(); } }) ); await Promise.all(tasks); await browser.close();p-limit(3)表示同时最多 3 个采集任务。这个数字要根据目标站点允许的并发量、你本机的内存、以及采集任务的时长来调整。我的建议是先从 1 开始逐步调到 3、5观察接口响应速度和报错率。如果响应时间明显变长说明已经对服务端造成压力了应该降回去。4.3 任务队列与断点续采采集几万条数据时中途失败在所难免。我的方案是维护一个任务队列文件每条任务记录状态pending、done、failed。每次启动脚本时先读队列只处理pending和failed的任务。简化版实现import fs from fs/promises; interface TaskItem { id: number; status: pending | done | failed; retryCount: number; } async function loadTasks(): PromiseTaskItem[] { try { return JSON.parse(await fs.readFile(tasks.json, utf-8)); } catch { return []; } } async function saveTasks(tasks: TaskItem[]) { await fs.writeFile(tasks.json, JSON.stringify(tasks, null, 2)); }这个文件就是断点续采的核心。任务跑挂了重启脚本后它会自动跳过已经完成的只处理剩余和失败的。配合.finally块确保每次任务结束都会更新状态。4.4 数据输出JSON 落盘与数据库写入采集到的数据最终要落库。我一般分两步走先把原始 JSON 原样存到本地再单独跑一个清洗脚本来解析、去重、入库。这样采集和数据处理解耦采集挂了不影响清洗清洗逻辑改了也不用重新采集。输出 JSON 文件很简单import fs from fs/promises; await fs.writeFile(data.json, JSON.stringify(results, null, 2), utf-8);如果要写入数据库我习惯用better-sqlite3这种同步 API 的库玩法简单适合中小型采集任务import Database from better-sqlite3; const db new Database(crawler.db); db.exec( CREATE TABLE IF NOT EXISTS products ( id INTEGER PRIMARY KEY, name TEXT, price REAL, crawled_at TEXT DEFAULT CURRENT_TIMESTAMP ) ); const insert db.prepare(INSERT OR REPLACE INTO products (id, name, price) VALUES (?, ?, ?)); for (const item of results) { insert.run(item.id, item.name, item.price); }INSERT OR REPLACE这句很关键能保证按主键去重。跑第二次采集时重复数据会覆盖而不是堆积。5. 常见问题与排查技巧实录5.1 登录态过期与 Token 版本不兼容我用 Playwright 接管 GitLab 等开发工具的 API 采集时经常会碰到一个错误login failed. check api token or gitlab version. log in via git if the version...这个报错的排查逻辑值得分享。它说的是 API Token 失效或当前 GitLab 版本不兼容客户端协议但用 Playwright 浏览器访问网页版却一切正常。问题通常出在你在脚本里直接调用的 API 依赖一个已经过期或权限不足的 Token而浏览器里的网页是走会话 Cookie 的。解决方案有两个在浏览器上下文里打开一个内部页从 LocalStorage 或页面脚本中读取出当前会话的 Token再注入到 API 请求里。更省心的办法不直接调 API而是先访问页面让页面自己调接口再通过监听response拿数据这样完全绕开了手动管理 Token 的问题。这个问题给我的教训是当“页面正常但脚本报错”时优先检查你是不是在做“双份身份认证”。浏览器已经帮你维护了一份身份你又额外塞了一个 Token两套认证规则不一致时就会出奇怪的问题。5.2 接口返回 400 或 payload 过大有段时间我在调用一个 AI 大模型类接口时总会遇到api error: 400 this models maximum context length is 1048576 tokens...这个报错的意思是我传入的 prompt 或上下文内容超过了模型允许的 token 上限。虽然模型能接受 1048576 个 token但“系统提示词 历史记录 当前输入”加起来超过了限制。排查思路很简单把请求 payload 中的文本长度分段检查看哪一段超了。如果是采集并转发给模型的场景可以在构建 payload 之前先做截断或摘要function truncateText(text, maxTokens) { const maxChars maxTokens * 3; // 粗略按 1 token ≈ 3-4 字符估算 if (text.length maxChars) return text; return text.slice(0, maxChars) ...; }当然这个粗暴截断只适合临时调试生产环境建议用官方 SDK 提供的 tokenizer 精确计算长度。5.3 页面内 iframe 的接口抓不到SPA 站点经常把部分模块塞进 iframe 里比如地图、支付、聊天组件。用page.on(response)只能监听主 frame 的请求iframe 里的 XHR 不会触发主 page 的 response 事件。处理方式是用page.on(framenavigated)或监听所有 frame 的 responsepage.on(response, async (response) { const frame response.frame(); // 判断 frame 是否是由 iframe 创建的 if (frame ! page.mainFrame()) { // 这里是 iframe 的响应 } });实际上page.on(response)默认也会覆盖所有子 frame 的响应但如果你发现漏了可以挨个遍历 frame 检查for (const frame of page.frames()) { if (frame.url().includes(important-module)) { // 单独处理这个 frame } }如果目标接口在 iframe 里你还需要先切换到对应 frame 才能执行 evaluateconst frame page.frames().find((f) f.url().includes(/embed/)); if (frame) { const data await frame.evaluate(() window.someGlobalData); }5.4 动态 JavaScript 混淆与浏览器指纹检测有朋友问我为什么有些站点用 Playwright 跑起来会卡在验证页。这种站点通常对运行时环境做检测包括navigator.webdriver属性、浏览器窗口尺寸、鼠标行为轨迹、是否安装了某些插件等。Playwright 会暴露出少量自动化特征的痕迹比如navigator.webdriver为true。我的建议是不要在对抗检测上花太多时间而是尽量让浏览器行为接近真人。比如使用非无头模式跑登录和复杂操作。给每个 context 设置不同的 user agent、viewport、locale。操作之间加入随机等待。尽量减少不必要的自动化操作频率。const context await browser.newContext({ userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36, viewport: { width: 1920, height: 1080 }, locale: zh-CN, timezoneId: Asia/Shanghai, });还有一个细节是headless: false时浏览器会弹出窗口生产环境不适合。我的方案是只在登录和调试阶段用有头模式正式采集时尽量切到无头。如果必须无头又要过检测那就需要额外处理 webdriver 属性但这类方法随时可能失效我一般不作为长期依赖。这里也顺便说一句所有采集行为都应该遵守目标站点的服务条款和 robots 协议采集频次控制在对目标服务器无压力的范围内。能用官方 API 的地方优先用官方 API。5.5 浏览器内存泄漏与崩溃长跑采集任务最常见的故障就是内存逐渐涨满最终浏览器崩溃。这种情况主要是因为创建了大量 context 和 page但释放不及时或者单个 context 里积累了太多历史记录。我采取的策略有三个用browser.newContext()时为每个 Task 创建独立 context任务结束后立即await context.close()。定期重启浏览器实例。比如每处理 500 个 Task就关闭当前 browser重新chromium.launch()。启动时加上内存限制参数const browser await chromium.launch({ args: [ --disable-dev-shm-usage, --memory-pressure-off, --no-sandbox, ], });--disable-dev-shm-usage在 Linux 服务器上特别重要否则/dev/shm太小会导致页面崩溃。6. 与 Python 爬虫、AI 大模型结合的新方向6.1 Playwright 能不能彻底替代 Requests 或 Scrapy很多初学者会纠结 Playwright 和 Python 爬虫生态怎么选。我的观点很直接.NET 或 Node 系的 Playwright 擅长的是“浏览器环境内的采集”而 Python 系的 Requests、Scrapy 擅长的是“纯 HTTP 链路的高效采集”。两者不是替代关系而是互补关系。对比维度Requests / ScrapyPlaywright请求效率高单机可并发几百上千低单实例并发个位数到十几反爬对抗弱需要手动处理签名和验证码强浏览器自带完整环境资源开销低高每个实例几百 MB 内存适合场景开放接口、数据量大的任务复杂登录、动态签名、需验证的站点我在实际项目里的分工方式是先用 Playwright 探路把目标接口的请求参数、加密逻辑摸清楚如果能做到纯 HTTP 复现就迁移到 Scrapy 做大规模采集如果复现不了就保持 Playwright 方案但降低并发。6.2 AI 在爬虫里的角色不是“替代”而是“辅助”你可能会想现在 ChatGPT 这么强能不能直接让它写爬虫我的回答是AI 能帮你快速写代码但爬虫的本质难点从来没变过那就是“了解目标的业务逻辑”。在基于 Playwright 的采集方案里AI 的切入点有三个分析 Network 面板导出的 HAR 文件识别目标接口的参数依赖关系。根据接口返回的 JSON 结构自动生成 TypeScript interface 定义。处理响应数据时用自然语言描述清洗规则让模型生成转换代码。举一个我最近用的例子导出 HAR 文件后我让 AI 帮我总结出哪个参数是 timestamp、哪个是签名、哪个来自 Cookie它几分钟就给了结果。这个过程换成人工坐在 DevTools 面前看至少得半小时。但是AI 生成的代码不一定稳定尤其是涉及 Playwright 这种异步事件较多的 API建议把 AI 生成的结果当作“第一版草稿”配合你自己的调试工具跑通后才能正式使用。6.3 大模型辅助数据清洗把接口数据变成结构化知识采集到的接口数据往往是原始 JSON真正要在业务中用还得做清洗。我之前做过一个功能把采集到的文章列表丢给大模型让它提取标题、作者、发布时间、摘要、关键词输出成结构化字段。这个过程如果用正则写逻辑会非常脆弱用大模型则能容忍各种格式变化。核心调用思路const prompt 这是从页面接口采集到的数据请提取其中与用户评价相关的字段并输出 JSON。 原始数据${JSON.stringify(rawData)} ; const resp await fetch(https://api.llm.example.com/v1/chat/completions, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ model: your-model, messages: [{ role: user, content: prompt }], response_format: { type: json_object }, }), });注意大模型的 context 有长度上限原始数据过大时要先截断或分片。这个和前面提到的 token 超限问题正好衔接上。我个人建议把 AI 清洗放在本地做不要让采集主流程依赖外部模型接口。这样即使模型服务临时故障原始数据也已经落盘随时可以重跑清洗任务。7. 最后分享一点我的踩坑心得整套方案跑了大半年最有价值的一个教训是不要一上来就追求“全自动”先把核心链路的每一步拆开单独调试。Playwright 用起来快但一旦出问题堆栈信息往往很抽象尤其涉及page.evaluate里的异步逻辑时错误往往只报一个泛泛的Evaluation failed。这时候唯一的调试办法就是分段打印日志、逐步验证。另一个很实用的技巧是在开发阶段把headless: false打开看到浏览器实际操作过程。虽然会弹出一个窗口有点烦但它能让你瞬间发现选择器选错了、页面弹了验证码、接口被拦截等问题。等确认没问题了再切回无头模式跑批量任务。采集工程从来不是“写一次就能永远跑”的它更像是一个需要持续维护的数据管道。站点改版、接口换参数、登录态失效、风控策略升级这些都会让脚本突然失灵。我的建议是最重要的不是写出一段能跑的代码而是设计好“出了问题后的恢复机制”。断点续采、日志记录、状态文件、超时熔断这些工程细节才是这套方案能长期稳定的根本。