Playwright的route拦截支持修改请求头、查询参数、请求体及伪造响应，但不支持底层URL重写；需在导航前注册，且必须调用continue()、fulfill()或abort()之一。
Playwright 中 intercept 的真实能力边界
Playwright 的 route 方法确实能拦截请求，但「修改 API 请求」这件事要分两层看：它支持修改请求头、查询参数、请求体（POST/PUT）、甚至完全伪造响应；但它不支持在浏览器发起前“劫持并重写 URL”这种底层网络层操作——那是 Puppeteer 的 page.setRequestInterception(true) 风格，而 Playwright 用的是更声明式、基于路由匹配的机制。实际开发中，绝大多数需求（比如 mock 接口、注入 token、屏蔽埋点、替换测试数据）用 page.route() 就够了，别一上来就想 hook TCP 层。
用 page.route() 拦截并改写请求体或 headers
关键在于匹配后调用 route.fulfill() 或 route.continue_()，且必须显式调用其中之一，否则请求会挂起。常见错误是忘了 await route.continue_() 或漏了 await 导致协程未执行。
- 匹配所有
/api/user请求：await page.route("**/api/user**", handler) - 想加 header？不能直接改
route.request.headers（只读），得在continue_()里传headers参数：await route.continue_(headers={**route.request.headers, "X-Debug": "true"}) - 想改 POST body？先
await route.request.post_data_json()解析，修改后再用continue_(post_data_json=new_data) - 注意：若原始请求是
application/x-www-form-urlencoded，post_data_json()会抛Error: Response body is not JSON，此时要用post_data()手动解析字符串
用 route.fulfill() 返回伪造响应时的坑
mock 接口最常用，但容易出错的地方很具体：
-
fulfill()必须提供status、headers和body（或json）三者之一，缺一不可；只传json=...时，Content-Type不会自动设为application/json，得手动加：headers={"Content-Type": "application/json"} - 如果原请求是 CORS 请求（带
Originheader），而你fulfill()返回没带Access-Control-Allow-Origin，前端 fetch 仍会报 CORS error —— 这不是 Playwright 的问题，是你 mock 响应没配全跨域头 - 不要在
fulfill()里返回大文件（如图片 base64），Playwright 对响应体大小有限制（默认约 10MB），超限会静默失败或报net::ERR_FAILED
全局拦截 vs 页面级拦截：作用域和时机差异
browser_context.route() 是全局的，对 context 内所有页面生效；page.route() 只对当前页面有效。但更重要的是时机：route 注册必须在页面导航前完成，否则可能错过初始 HTML 加载时发出的 API 请求（比如 SPA 的首屏数据请求）。常见错误是等 page.goto() 完成后再注册 route。
立即学习“Python免费学习笔记（深入）”；
- 正确做法：
await page.route(...); await page.goto("https://example.com") - 如果要拦截 Service Worker 控制下的请求（如缓存策略为
network-first），route 依然有效，但 SW 可能已从缓存返回，此时请求根本不会发到网络层 —— route 拦不到，得关掉 SW 或用page.add_init_script("navigator.serviceWorker.getRegistrations().then(r => r.forEach(reg => reg.unregister()))") - 注意
page.route()不影响fetch()在 Web Worker 中发起的请求，Worker 独立于页面上下文
真正麻烦的从来不是怎么写 route，而是搞清请求到底从哪来：是主文档加载触发的？是 JS 动态 fetch 的？被 Service Worker 拦了？还是被 CSP 策略 block 了？先打开浏览器 DevTools 的 Network 标签页确认请求行为，再决定 route 放在哪、怎么匹配。否则光靠猜，90% 的“拦截失效”都源于作用域或时机误判。
