Playwright无法直接修改请求头，只能拦截后中止再重发；route.continue()已移除headers参数，需用route.abort()配合fetch手动发带自定义头的请求。
Playwright如何拦截请求并修改请求头？
Playwright 本身不支持直接“修改”已发出的请求包（比如篡改 Host 或 Authorization 后再发出去），但它能在请求发出前通过 route 拦截，然后用新参数发起替代请求。关键不是“改原包”，而是“拦住、丢弃、重发”。
常见错误现象是调用 route.continue() 后试图改 headers —— 这无效，continue() 不接受 headers 参数（Playwright 1.40+ 已移除该支持）。
使用场景包括：添加认证 token、绕过 referer 校验、模拟移动端 UA、屏蔽特定资源。
实操建议如下：
立即学习“Python免费学习笔记（深入）”；
- 用
page.route()匹配 URL（支持 glob、regex、lambda） - 在回调中调用
route.fulfill()返回伪造响应，或route.continue()放行 - 若需“修改后重发”，必须用
route.abort()中止，再用page.goto()/fetch()手动发新请求（注意上下文隔离问题）
page.route("**/api/user", lambda route: route.fulfill(
status=200,
headers={"Content-Type": "application/json"},
body='{"id": 123, "name": "mock"}'
))
如何用 route.continue() 附带自定义 headers？
不能。Playwright 的 route.continue() 从 1.39 版本起彻底移除了 headers 参数。强行传入会报错：TypeError: continue() got an unexpected keyword argument 'headers'。
如果你依赖旧文档示例，大概率是在看 v1.38 或更早版本。现在唯一合法方式是：拦截 → 中止 → 自行构造 fetch 请求，并在其中设置 headers。
性能影响明显：每次拦截后手动 fetch，会多一次网络往返，且无法复用浏览器内置缓存和 cookie 上下文（除非你显式传 credentials: 'include'）。
实操建议：
SkillSub Pro - Python 题解与代码注释双功能技能功能概述SkillSub Pro - Python 题解与代码注释双功能技能是一项面向实际任务的技能，主要用于SkillSub Pro 是一个 Python 题解生成与代码注释的 双功能合体技能 ，专为学生、算法学习者和开发者设计；✅ 一个技能，两种用途 ：；核心要点📝 题解模式 ：输入题目/题号，自动生成完整 Python 题解（含详细注释、解题思路、复杂度分析）；💬 注释模式 ：输入 Python 代码，自动添加详细中。它将相关步骤、
- 不要尝试 patch
route.continue或 monkey patch Playwright 内部逻辑 - 如只需加 headers，优先考虑在页面 JS 中覆盖
fetch全局函数（适用于可控前端环境） - 真需要服务端级 header 注入，应改用 mitmproxy + Playwright 启动时指定代理（
proxy配置项）
拦截请求后怎么获取原始请求体（如 POST body）？
Playwright 默认不暴露原始 body。调用 route.request().post_data() 只对 application/x-www-form-urlencoded 和纯文本有效；对 application/json 或二进制内容返回 None。
常见错误现象是打印 route.request().post_data() 得到 None，误以为没捕获到，其实是类型不支持。
原因在于 Chromium 内核限制：非文本型 body（如 FormData、Blob、ArrayBuffer）在路由拦截阶段不可读。
实操建议：
- 用
route.request().headers()和route.request().method()做初步判断 - 若必须读 JSON body，可在页面中注入脚本，把
fetch/XMLHttpRequest的 body 提前序列化并挂到window上，再由 Python 侧通过page.evaluate()读取 - 或启用
recordHar选项导出 HAR 文件，离线解析（适合调试，不适合实时修改）
为什么 route 拦截不到某些请求（比如 iframe 或预加载资源）？
默认 page.route() 只作用于当前 page context 下的主帧请求。iframe、worker、prefetch、preload、manifest 等资源可能属于不同上下文或由浏览器预加载，不在监听范围内。
典型表现：页面里有个 <iframe src="/data">，但 page.route("/data") 完全不触发。
原因有三：
- iframe 使用独立的
frame对象，需对frame.route()单独注册 -
prefetch/preload请求走的是浏览器预加载管道，不经过普通网络栈拦截点 - Service Worker 控制的请求，可能被 SW 拦截并响应，根本不会到达 Playwright 路由层
实操建议：
- 对已知 iframe，用
page.frame_locator("iframe").content_frame().route(...)（v1.40+ 推荐写法） - 用
page.on("request")监听所有发出请求（只读，不能拦截修改） - 启动浏览器时加
ignoreHTTPSErrors=True和acceptDownloads=True，避免因证书或下载中断导致部分请求静默失败
Playwright 的请求拦截本质是基于 Chromium 的 DevTools Protocol 的 Network.setInterception，它天然有上下文边界和协议限制。想做到“全量可修改”，得接受它不是抓包工具，而是自动化驱动工具——该让步的时候，就得换 mitmproxy 或自己搭中间层。
