1. 项目概述：为什么我们需要在自动化中修改请求参数？

做Web自动化测试或者数据抓取的朋友，肯定都遇到过这样的场景：你写好的脚本，对着一个网页或者接口一顿操作，结果要么是数据没抓到，要么是提交的表单不对，要么是页面跳转逻辑和你预期的不一样。很多时候，问题就出在那些你看不见摸不着的网络请求上。一个GET请求的查询参数（Query String）里可能藏着一个动态生成的token，一个POST请求的请求体（Body）里可能有个根据时间戳计算的签名。如果你只是机械地模拟点击和输入，而不去干预这些请求的“内里”，你的自动化流程很可能在第一步就卡住了。

这就是我们今天要聊的核心： 使用Python的Playwright框架，在自动化流程中拦截并修改HTTP请求的GET/POST参数 。这不仅仅是“抓包”看看数据流那么简单，而是主动介入，在请求发出去之前，按我们的需求“改写”它。想象一下，你是一个交通调度员，不仅能看到所有车辆（请求）的行驶路线，还能在它们出发前，临时更改它们的载货清单（请求参数）或者目的地（请求头），以确保它们能顺利通过检查站（服务器验证）。Playwright提供的 page.route() 和 request.continue() 方法，就是赋予我们这种能力的“调度指令”。

为什么是Playwright，而不是传统的Selenium加上 mitmproxy 或者 Fiddler ？最大的优势在于 一体化 和 无侵入性 。Playwright是一个“自带干粮”的现代化浏览器自动化库，它原生支持对网络请求的监听与修改，无需额外配置代理服务器，也避免了代理可能带来的证书信任、端口冲突等麻烦。你可以在同一个Python脚本里，既完成浏览器操作的自动化，又精细地控制网络层，这对于构建稳定、可复现的测试用例或数据采集流程至关重要。无论是为了绕过前端反爬机制、构造特定的测试数据、模拟异常请求场景，还是单纯为了调试和理解应用的数据流，掌握这项技术都像拿到了一把打开Web应用“后门”的钥匙。

2. 核心思路与Playwright路由机制解析

在动手写代码之前，我们必须先理解Playwright处理网络请求的核心机制—— 路由（Routing） 。这是整个技术方案的基石。

简单来说，Playwright允许你在一个页面（ Page ）对象上设置一个“路由处理器”。每当这个页面即将发起一个网络请求（无论是点击链接触发的导航，还是XHR/Fetch API发起的Ajax请求），这个请求都不会直接发送到网络，而是先“路过”你设置的这个处理器。此时，你有权决定这个请求的命运：是放行（可能修改后放行），是阻止，还是用一个自定义的响应来“搪塞”它。

这个过程主要涉及两个核心对象：

1. Route对象 ：代表一个被拦截的请求。它包含了这个请求的所有信息：URL、方法（GET/POST）、请求头（Headers）、请求体（Post Data）等。更重要的是，它提供了决定请求下一步操作的方法，主要是 route.continue() 、 route.fulfill() 和 route.abort() 。
2. Request对象 ：通常作为参数传递给路由处理函数。你可以通过它来读取请求的详细信息。但请注意， Request 对象本身是只读的。你不能直接修改 request.url 或 request.post_data 。修改的操作，需要通过 Route 对象来完成。

那么，修改请求参数的流程是怎样的呢？其核心思想是“ 先拦截，再构造，后放行 ”。

第一步：拦截（Intercept） 使用 page.route(url_pattern, handler) 方法。 url_pattern 可以是一个字符串（支持通配符 * ），也可以是一个正则表达式（ re.compile ），用于匹配你想要拦截的请求URL。 handler 是一个异步回调函数，它接收 Route 和 Request 两个参数。

第二步：构造新请求（Construct） 在 handler 函数内部，我们根据原始请求（ Request 对象）的信息，构建我们想要发送的新请求参数。这是最关键的一步：

• 对于 GET请求 ，参数通常附在URL的 ? 之后，如 https://api.example.com/data?page=1&keyword=test 。我们需要解析这个URL，修改其中的查询参数，然后拼装成一个新的URL。
• 对于 POST请求 ，参数可能在URL中（类似GET），但更常见的是在请求体（Body）中，格式可能是 application/x-www-form-urlencoded （表单格式）、 application/json （JSON格式）或 multipart/form-data （文件上传）。我们需要根据 Content-Type 请求头，解析原始请求体，修改数据，再重新编码。

第三步：放行（Continue） 调用 route.continue() 方法，并将我们构造好的新参数传递给它。Playwright会使用我们提供的新参数，重新发起这个请求。如果调用 route.continue() 时不提供任何参数，则使用原始请求参数放行。

这里有一个非常重要的细节： route.continue() 方法接受一个可选的字典参数，例如 route.continue_(method=‘POST’, post_data=modified_data, headers=modified_headers) 。注意，这里的参数是 覆盖式 的。如果你只提供了 post_data ，那么新的请求会使用原始的 method 和 headers ，但 post_data 会被替换成你提供的。这意味着，如果你修改了POST的JSON数据，你必须确保 headers 里的 Content-Length 也同步更新为新的数据长度，否则服务器可能会拒绝这个请求。Playwright在某些版本中会自动处理 Content-Length ，但为了代码的健壮性和可理解性，我建议手动处理或明确知晓其行为。

注意 ： route.continue() 方法在Playwright的Python API中写作 route.continue_ （后面有个下划线），因为 continue 是Python的关键字。这是新手很容易踩的一个坑，直接写 route.continue() 会导致语法错误。

3. 实战准备：环境搭建与基础脚本骨架

理论讲得再多，不如一行代码。我们先从最基础的环境搭建和脚本骨架开始。确保你已经安装了Python（建议3.7及以上版本）。接下来，我们通过命令行来安装Playwright。

打开你的终端或命令提示符，执行以下命令：

pip install playwright

安装完库之后，Playwright还需要下载它要控制的浏览器内核（Chromium, Firefox, WebKit）。你可以一次性全部下载，但通常我们只需要Chromium就够了。执行下面的命令：

playwright install chromium

这个步骤可能会花费一些时间，因为它需要下载几百兆的浏览器文件，请保持网络通畅。如果遇到网络问题，可以考虑配置镜像源，或者使用 playwright install --help 查看是否有离线安装选项。

环境就绪，现在我们来创建一个最基础的、具备请求拦截功能的脚本骨架。这个骨架将是后续所有示例的基础。

import asyncio
from playwright.async_api import async_playwright
import re

async def main():
    # 启动Playwright，创建一个浏览器上下文
    async with async_playwright() as p:
        # 启动一个Chromium浏览器实例，headless=False表示显示浏览器界面，方便调试
        browser = await p.chromium.launch(headless=False)
        # 创建一个新的浏览器上下文（类似于隐身模式，独立cookies和缓存）
        context = await browser.new_context()
        # 在新上下文中打开一个空白页
        page = await context.new_page()

        # ！！！核心步骤：设置请求路由/拦截器
        # 这里使用一个通配符*，表示拦截该页面发起的所有请求
        # 在实际使用中，你应该替换成更具体的URL模式以提高性能
        await page.route('**/*', route_handler)

        # 导航到目标网站，触发网络请求
        await page.goto('https://httpbin.org/anything') # 这是一个用于测试HTTP请求的网站
        # 等待一段时间，观察请求和响应
        await page.wait_for_timeout(5000)

        # 关闭资源
        await context.close()
        await browser.close()

# 定义路由处理函数
async def route_handler(route, request):
    # 打印原始请求信息，便于调试
    print(f'拦截到请求: {request.method} {request.url}')
    # 默认行为：不做任何修改，直接放行
    await route.continue_()

# 运行主函数
asyncio.run(main())

把这段代码保存为 playwright_intercept_basic.py 并运行。你会看到一个浏览器打开并访问 httpbin.org ，同时在你的终端里，会打印出该页面加载过程中发起的所有请求（HTML、CSS、JS、图片、XHR等）。这说明我们的拦截器已经生效了。

实操心得一：关于拦截范围与性能 在上面的骨架中，我们使用了 **/* 这个通配符来匹配所有请求。这在调试阶段非常有用，可以让你看清页面所有的网络活动。但在正式脚本中， 强烈建议你将拦截范围缩小到具体的目标请求 。例如，如果你只关心某个特定的API接口，可以使用 **/api/userInfo 或 re.compile(r‘.*/api/.*\.json$‘) 这样的模式。拦截所有请求会显著增加脚本的开销，并可能导致一些非目标请求被意外修改，引入不确定性。一个好的实践是，先通过浏览器的开发者工具（F12 -> Network）找到你需要修改的请求的URL特征，再用这个特征去构造你的 url_pattern 。

4. 核心环节一：拦截并修改GET请求参数

GET请求的参数是挂在URL后面的，修改起来相对直观。我们的目标是：拦截一个GET请求，解析它的查询字符串（Query String），修改其中的某些参数值，然后用新的URL放行这个请求。

假设我们有一个搜索请求，URL是 https://example.com/search?q=playwright&page=1&sort=desc 。我们现在想将 page 参数从 1 改为 2 ，并且新增一个参数 filter=active 。

我们来编写具体的路由处理函数：

from urllib.parse import urlparse, parse_qs, urlencode, urlunparse

async def modify_get_request(route, request):
    # 1. 检查是否为GET请求
    if request.method != ‘GET‘:
        await route.continue_()
        return

    # 2. 解析原始URL
    parsed_url = urlparse(request.url)
    # 解析查询参数，parse_qs返回的是字典，值是列表（因为一个参数可以有多个值）
    query_params = parse_qs(parsed_url.query)

    print(f‘修改前参数: {query_params}‘)

    # 3. 修改参数
    # 修改page参数
    if ‘page‘ in query_params:
        query_params[‘page‘] = [‘2‘] # 注意这里赋值的是列表
    # 新增filter参数
    query_params[‘filter‘] = [‘active‘]

    print(f‘修改后参数: {query_params}‘)

    # 4. 重新编码查询字符串
    # urlencode可以将字典编码为查询字符串，doseq=True正确处理列表值
    new_query_string = urlencode(query_params, doseq=True)
    # 构造新的URL组成部分
    new_url_components = parsed_url._replace(query=new_query_string)
    # 组装成完整的URL
    new_url = urlunparse(new_url_components)

    # 5. 用新的URL继续请求
    await route.continue_(url=new_url)

然后，在主函数 main() 中，将路由注册改为更有针对性的模式，并指定这个处理函数：

# 假设我们只拦截包含‘/search‘的请求
await page.route(‘**/search*‘, modify_get_request)
# 然后导航到会触发搜索的页面
await page.goto(‘https://example.com/search-page‘)
await page.click(‘button#search‘) # 假设点击按钮触发搜索

关键点与避坑指南：

1. parse_qs 的返回值 ： parse_qs(‘a=1&a=2&b=3‘) 会返回 {‘a‘: [‘1‘, ‘2‘], ‘b‘: [‘3‘]} 。这是一个将参数名映射到 值列表 的字典。因为URL中同一个参数名可以出现多次（如多选框）。在修改时，我们赋值也需要赋值为列表，即使只有一个值。
2. urlencode 的 doseq 参数 ：当我们将 {‘a‘: [‘1‘, ‘2‘]} 这样的字典编码回查询字符串时，需要设置 doseq=True ，它才会生成 a=1&a=2 。如果 doseq=False ，它会尝试把整个列表当成一个值来处理，导致错误。
3. URL的完整性 ： urlunparse 需要传入一个包含6个元素的元组（协议、网络位置、路径、参数、查询、片段）。我们使用 parsed_url._replace(query=...) 来生成一个只替换了查询部分的新元组，这是最安全、最不容易出错的方式，能保留原始URL的其他所有部分（如锚点 #fragment ）。
4. 性能考虑 ：在路由处理函数中，尽量只对目标请求进行复杂的解析和修改逻辑。对于不需要修改的请求，尽早调用 await route.continue_() 并返回，以减少不必要的处理开销。

5. 核心环节二：拦截并修改POST请求参数（表单与JSON）

POST请求的修改比GET要复杂一些，因为它的参数可能藏在请求体里，并且格式多样。最常见的两种是 application/x-www-form-urlencoded （标准表单提交）和 application/json 。我们需要根据 Content-Type 请求头来区别处理。

5.1 修改表单格式（application/x-www-form-urlencoded）的POST请求

这种格式的请求体看起来和GET的查询字符串一模一样： key1=value1&key2=value2 。我们可以用处理GET参数类似的方式来解析和修改。

from urllib.parse import parse_qs, urlencode

async def modify_post_form_request(route, request):
    # 1. 检查是否为POST请求且内容类型是表单
    if request.method != ‘POST‘:
        await route.continue_()
        return
    content_type = request.headers.get(‘content-type‘, ‘‘)
    if ‘application/x-www-form-urlencoded‘ not in content_type:
        await route.continue_()
        return

    # 2. 获取原始POST数据（字节串）
    post_data = request.post_data
    if not post_data:
        await route.continue_()
        return

    # 3. 解析表单数据
    # post_data是字符串，例如 ‘username=test&password=123456‘
    form_params = parse_qs(post_data) # 同样返回字典{‘username‘: [‘test‘], ...}

    print(f‘修改前表单数据: {form_params}‘)

    # 4. 修改数据
    # 例如，修改密码字段
    if ‘password‘ in form_params:
        form_params[‘password‘] = [‘modified_789‘]
    # 新增一个字段
    form_params[‘csrf_token‘] = [‘fake_token_abc‘]

    print(f‘修改后表单数据: {form_params}‘)

    # 5. 重新编码表单数据
    new_post_data = urlencode(form_params, doseq=True)

    # 6. 准备新的请求头（可选，但建议更新Content-Length）
    new_headers = dict(request.headers) # 复制原始头
    new_headers[‘content-length‘] = str(len(new_post_data.encode(‘utf-8‘))) # 计算新数据长度

    # 7. 用新数据和新头继续请求
    await route.continue_(post_data=new_post_data, headers=new_headers)

5.2 修改JSON格式（application/json）的POST请求

现代Web API大量使用JSON。修改JSON请求体，本质上就是解析JSON字符串，修改Python字典对象，再序列化回JSON字符串。

import json

async def modify_post_json_request(route, request):
    if request.method != ‘POST‘:
        await route.continue_()
        return
    content_type = request.headers.get(‘content-type‘, ‘‘)
    if ‘application/json‘ not in content_type:
        await route.continue_()
        return

    post_data = request.post_data
    if not post_data:
        await route.continue_()
        return

    # 1. 解析JSON数据
    try:
        json_data = json.loads(post_data) # 将字符串解析为Python字典/列表
    except json.JSONDecodeError as e:
        print(f‘无法解析JSON: {e}，使用原始数据放行‘)
        await route.continue_()
        return

    print(f‘修改前JSON数据: {json.dumps(json_data, indent=2)}‘)

    # 2. 修改JSON数据
    # 例如，假设JSON结构是 {“query”: “python”, “page”: 1}
    if ‘page‘ in json_data and isinstance(json_data[‘page‘], int):
        json_data[‘page‘] = 2
    # 添加一个新字段
    json_data[‘source‘] = ‘modified_by_playwright‘

    print(f‘修改后JSON数据: {json.dumps(json_data, indent=2)}‘)

    # 3. 重新序列化为JSON字符串
    new_post_data = json.dumps(json_data)

    # 4. 更新请求头（特别是Content-Length）
    new_headers = dict(request.headers)
    new_headers[‘content-length‘] = str(len(new_post_data.encode(‘utf-8‘)))

    # 5. 继续请求
    await route.continue_(post_data=new_post_data, headers=new_headers)

实操心得二：处理Content-Length的坑 这是一个非常关键且容易出错的地方。当你修改了POST的请求体数据后，数据的长度（字节数）几乎一定会发生变化。HTTP协议要求请求头中的 Content-Length 必须精确等于请求体的字节长度。如果你修改了数据但没有更新这个头，服务器在接收请求时，可能会：

• 等待接收更多数据（如果新数据比原数据短），导致请求超时。
• 截断数据（如果新数据比原数据长），导致数据不完整，解析失败。
• 直接返回 400 Bad Request 。

因此， 在修改了 post_data 后，手动计算新数据的字节长度并更新 headers[‘content-length‘] 是一个必须养成的好习惯 。注意，计算长度时要用 .encode(‘utf-8‘) 将字符串转换为字节串，因为网络传输的是字节。 len(new_post_data) 得到的是字符数，对于中文等非ASCII字符，字符数和字节数是不相等的。

6. 综合实战：模拟一个完整的登录参数篡改场景

让我们把所有知识串联起来，模拟一个经典的自动化测试场景： 修改登录请求中的密码字段，以验证服务端对错误密码的处理逻辑 。

假设我们有一个登录页面，用户名固定，但我们需要测试输入错误密码时系统的响应。我们不想在UI层输入错误的密码，而是想在网络请求层“偷梁换柱”。

步骤拆解：

1. 启动浏览器，打开登录页。
2. 在页面加载后、任何请求发起前，设置路由拦截，目标是与登录API匹配的URL模式。
3. 在UI上正常输入正确的用户名和密码（例如，通过 page.fill(‘#username‘, ‘admin‘) 和 page.fill(‘#password‘, ‘correct_password‘) ）。
4. 点击登录按钮。
5. 登录请求被我们的拦截器捕获。拦截器将请求体中的密码从 correct_password 修改为 wrong_password 。
6. 请求被放行，携带错误密码发送到服务器。
7. 我们捕获服务器的响应，验证是否返回了预期的错误信息（如“密码错误”）。

import asyncio
import json
from playwright.async_api import async_playwright

async def login_test():
    async with async_playwright() as p:
        browser = await p.chromium.launch(headless=False) # 显示浏览器以便观察
        context = await browser.new_context()
        page = await context.new_page()

        # 定义拦截处理器
        async def hijack_login_request(route, request):
            if request.method == ‘POST‘ and ‘/api/login‘ in request.url:
                print(f‘拦截到登录请求: {request.url}‘)
                # 假设是JSON格式的登录请求
                try:
                    json_body = json.loads(request.post_data or ‘{}‘)
                    original_pwd = json_body.get(‘password‘, ‘N/A‘)
                    print(f‘原始密码字段值: {original_pwd}‘)

                    # 篡改密码
                    json_body[‘password‘] = ‘deliberately_wrong_password‘
                    new_post_data = json.dumps(json_body)

                    # 更新头信息
                    new_headers = dict(request.headers)
                    new_headers[‘content-length‘] = str(len(new_post_data.encode(‘utf-8‘)))

                    print(‘密码已篡改，准备发送错误密码请求...‘)
                    # 放行修改后的请求
                    await route.continue_(post_data=new_post_data, headers=new_headers)
                except Exception as e:
                    print(f‘处理登录请求时出错: {e}‘)
                    await route.continue_() # 出错则原样放行
            else:
                # 非登录请求，直接放行
                await route.continue_()

        # 注册路由，这里使用更精确的URL匹配模式
        await page.route(‘**/api/login‘, hijack_login_request)

        # 导航到登录页（这里用一个模拟页面，实际替换为你的目标URL）
        await page.goto(‘https://your-test-site.com/login‘)

        # 在UI上输入“正确”的凭证
        await page.fill(‘input[name=“username”]‘, ‘test_user‘)
        await page.fill(‘input[name=“password”]‘, ‘correct_password‘) # UI上输入的是正确的

        # 为了捕获登录响应，我们可以监听响应事件
        login_response_info = {}
        def handle_response(response):
            if ‘/api/login‘ in response.url:
                login_response_info[‘status‘] = response.status
                login_response_info[‘url‘] = response.url
                try:
                    # 尝试解析JSON响应
                    login_response_info[‘body‘] = asyncio.run(response.json())
                except:
                    # 如果不是JSON，获取文本
                    login_response_info[‘body‘] = asyncio.run(response.text())
                print(f‘登录响应状态: {response.status}‘)
        page.on(‘response‘, handle_response)

        # 点击登录按钮
        await page.click(‘button[type=“submit”]‘)

        # 等待一段时间，让请求和响应完成
        await page.wait_for_timeout(3000)

        # 输出响应结果，验证是否收到了密码错误的提示
        print(‘最终的登录响应信息:‘, login_response_info)
        # 这里可以添加断言，例如 assert login_response_info.get(‘status‘) == 401

        await context.close()
        await browser.close()

asyncio.run(login_test())

这个示例展示了如何将请求拦截、参数修改、响应监听结合在一起，完成一个完整的测试用例。它清晰地分离了“UI操作”（输入正确的密码）和“网络层验证”（发送错误的密码），使得测试逻辑更清晰，也更容易模拟各种边界情况。

7. 高级技巧与疑难问题排查

掌握了基础操作后，我们来看看一些更进阶的用法和实际开发中必然会遇到的“坑”。

7.1 选择性拦截与性能优化

拦截所有请求（ **/* ）在调试时很方便，但在正式脚本中会严重拖慢速度。你应该始终使用最精确的URL模式。

• 字符串匹配 ： page.route(‘**/api/v1/user/*‘, handler) 匹配所有以 /api/v1/user/ 开头的请求。
• 正则表达式匹配 ：功能更强大。

  import re
  pattern = re.compile(r‘.*\.(json|api)$‘) # 匹配以.json或.api结尾的请求
  await page.route(pattern, handler)
  

• 在Handler内部判断 ：如果URL模式无法精确过滤，可以在 handler 函数开头根据 request.url 或 request.method 进行判断，不符合条件的立即 route.continue_() 。

7.2 修改请求头（Headers）

除了修改参数，修改请求头也极为常见，例如添加一个认证Token，或者修改 User-Agent 来模拟移动端。

async def modify_headers(route, request):
    new_headers = dict(request.headers)
    # 添加或修改头信息
    new_headers[‘Authorization‘] = ‘Bearer your_token_here‘
    new_headers[‘User-Agent‘] = ‘Mozilla/5.0 (iPhone; ...)‘ # 模拟iPhone

    # 注意：修改了headers，通常也需要同步更新content-length（如果修改了body）
    # 这里假设只修改headers，body不变，所以直接传递原始post_data
    await route.continue_(headers=new_headers)

重要提醒 ：有些请求头是由浏览器自动管理并受保护的，如 Host , Connection , Content-Length 等。Playwright允许你修改它们，但不当的修改可能导致请求失败。修改 Content-Length 的注意事项前面已经强调过了。

7.3 处理multipart/form-data（文件上传）

这种格式的请求体结构复杂，包含了边界分隔符和二进制文件数据。直接像处理表单或JSON一样去解析字符串是行不通的。Playwright的 Request.post_data 对于 multipart/form-data 可能返回 None 或不可直接解析的数据。

解决方案 ：对于文件上传请求，如果你需要修改其中的文本字段，更推荐的做法是 不在网络层拦截修改，而是在UI层直接操作 。因为Playwright提供了非常方便的文件上传API：

# 直接设置文件输入框的值，而不是拦截请求去改二进制流
await page.set_input_files(‘input[type=“file”]‘, ‘path/to/your/file.txt‘)

如果你必须要在网络层处理，可以考虑使用 route.fulfill() 来完全模拟一个响应，而不是修改请求，但这超出了本文“修改请求参数”的范围，属于更高级的Mock技术。

7.4 常见问题排查实录

问题1：拦截器没生效，请求直接发出去了。

• 检查点1：路由注册时机 。确保 page.route() 是在 页面发起目标请求之前 调用的。通常，在 page.goto() 或点击按钮触发请求之前注册。如果请求是页面加载后由JavaScript动态触发的，确保路由在页面加载完成（ page.on(‘load‘) ）或相关元素出现后就注册好。
• 检查点2：URL模式匹配 。打印出 request.url ，检查它是否确实匹配你设置的 url_pattern 。注意URL可能包含查询参数或哈希，你的模式需要能覆盖到。
• 检查点3：Handler函数是否被调用 。在 handler 函数的第一行加个 print ，看看有没有输出。

问题2：修改参数后，服务器返回400或500错误。

• 检查点1：Content-Length 。这是最常见的坑！务必在修改 post_data 后重新计算并设置 headers[‘content-length‘] 。
• 检查点2：数据格式 。确保修改后的数据格式与服务器期望的一致。例如，将JSON中的一个数字 123 错误地改成了字符串 “123” ，可能导致后端反序列化失败。对比修改前后数据的完整结构。
• 检查点3：编码问题 。如果参数值包含中文等非ASCII字符，确保在计算长度和传输时使用正确的编码（通常是UTF-8）。 json.dumps() 默认产生的是Unicode字符串，其 len() 是字符数，不是字节数。

问题3： route.continue_() 报错，提示“Request is already handled”。

• 这意味着这个 Route 对象已经被处理过了（可能调用了 continue_() , fulfill() 或 abort() ）。每个被拦截的请求只能被处理一次。确保你的 handler 函数逻辑中没有重复调用这些方法，或者存在多个路由匹配同一个请求导致重复处理。检查你的代码路径，确保每个请求只进入一个最终的处理分支。

问题4：如何调试修改前后的请求详情？

• 在 handler 函数里详细打印 request.method , request.url , request.headers , request.post_data 。
• 使用 route.continue_() 之后，你还可以通过监听 page.on(‘request‘) 和 page.on(‘response‘) 事件来观察实际发出请求和收到响应的详情，与你的修改进行对比。
• 结合 headless=False 模式，打开浏览器的开发者工具（F12）的Network面板，可以直观地看到所有网络活动，这是最强大的调试手段。

8. 总结与最佳实践建议

通过上面的详细拆解，你应该已经掌握了使用Playwright修改GET/POST请求参数的全套技能。从简单的查询字符串修改，到复杂的JSON请求体篡改，再到完整的实战场景模拟。这项技术将你的Web自动化能力从“模拟用户操作”提升到了“控制网络通信”的维度，极大地增强了脚本的灵活性和威力。

最后，分享几条从实际项目中总结出的最佳实践：

1. 精确拦截 ：永远使用尽可能具体的URL模式来注册路由，避免不必要的性能开销和副作用。在 handler 内部也可以进行二次判断。
2. 保持健壮性 ：在 handler 函数中做好异常处理（ try...except ）。对于无法解析或处理的请求，记录日志并原样放行（ await route.continue_() ），避免因为一个请求的拦截失败导致整个脚本崩溃。
3. 同步Headers与Body ：只要修改了请求体，就一定要记得重新计算并设置 Content-Length 请求头。这是一个必须遵守的HTTP协议规范。
4. 善用监听器 ： page.on(‘request‘) , page.on(‘response‘) , page.on(‘requestfinished‘) 等事件监听器，是观察网络行为、调试拦截效果的利器。将它们与 page.route() 结合使用。
5. 考虑可测试性 ：将路由处理函数定义为独立的、可测试的函数。你可以编写单元测试，传入模拟的 route 和 request 对象，来验证你的参数修改逻辑是否正确，而不需要每次都启动浏览器。
6. 明确使用场景 ：这项技术非常强大，但请负责任地使用。主要用于自动化测试、数据抓取（在遵守 robots.txt 和网站条款的前提下）、前端调试等合法合规的场景。

掌握了Playwright的请求拦截与修改，你就如同拥有了Web应用的“遥控器”，可以更深入、更精准地控制自动化流程，应对各种复杂的交互场景。希望这篇详尽的指南能成为你手边常备的参考，助你在Web自动化的道路上走得更远更稳。如果在实践中遇到新的问题，不妨回头看看核心的“拦截-构造-放行”流程，以及关于 Content-Length 和编码的那些细节，大多数难题的答案都藏在其中。