企业官网建设流程全解析

简介：针对如何使用 Selenium 封装 POST 参数并提交的示例资源，面向 Web 自动化测试与接口联调场景中的测试工程师，特别是已有 Python 或 Java 基础的读者，用于解决异步请求中参数传递、表单模拟以及返回值解析提取等问题。压缩包仅 5KB，共包含 3 个文件：txt 说明文档给出整体思路与代码笔记，bak 为备份版本，java 文件则提供一个可参考的处理器类，方便对照不同语言的具体写法与封装思路。目前已有 3698 人学习或下载，说明许多开发者都遇到过类似需求，资源具有一定实践参考价值。内容不仅展示了基于 fetch 的 Python 封装方法，还补充了 execute_async_script 处理非 HTML 响应、添加请求头与认证信息、必要时改用 requests 库等关键细节，能帮助读者避免常见弯路。总体而言，这份资源小巧但完整，适合在自动化脚本中快速验证 POST 提交效果，并可作为后续扩展的起点。

1. 用Selenium封装POST参数：不是不会requests，是浏览器上下文丢不起

如果只看标题，很多人第一反应是：POST请求直接扔给requests库不就行了？但在真实的浏览器自动化场景里，我们会遇到登录后token存进localStorage、接口入参需要带上页面里某段JS动态生成的签名、或者表单提交前需要在浏览器里过一遍验证码。这类场景下，requests无法复用浏览器里已经建立好的会话和上下文，硬写给它的请求，常常因为少了某个cookie或某个请求头而被服务端拒绝。Selenium封装POST参数提交，目的就是把这些带状态的HTTP请求放进浏览器上下文里执行，让请求看起来和用户在页面上点击一样。它适合写爬虫和数据采集脚本的人，也适合做自动化测试时需要模拟特定提交参数的场景。下面的篇幅会给出可直接复制的封装函数，并说明哪条路容易翻车。

2. 为什么Selenium直接发POST会翻车：请求链路与选型逻辑

在动手写封装函数之前，先把问题拆开看一遍。Selenium本身没有提供“发送任意HTTP请求”的能力，这一决定有历史原因。WebDriver协议的命令集，是为了驱动浏览器用户界面而设计，而不是为了驱动浏览器网络层。你可以在协议里找到一个命令叫“导航到URL”，但它执行的是页面跳转，不是POST；可以找到一个命令调用元素单击，但它最终走的是渲染层的点击事件。到了网络层之后，浏览器究竟用什么方式产生请求，自动化脚本完全看不到，也控制不了。所以，把POST放进Selenium，本质上是一条侧路：要么借用页面里的JS运行时自己发fetch，要么预先把会话凭据倒进浏览器，再触发页面操作。

2.1 WebDriver的API边界：click与send_keys没有覆盖HTTP层

WebDriver原生提供的“发请求”方式，严格来说只有driver.get和driver.refresh两个。它们都产生一个GET导航请求，且请求发生时，脚本没有机会插入请求头或请求体。有些人尝试用driver.get("https://host/api?param1=xxx&param2=yyy")代替POST，这在语义上就变了：服务端可能根据是否POST决定路由，也可能在GET里区分查询参数和body参数，更可能因为get参数过长直接被网关拒绝。

另一种常见尝试是把页面里的表单find_element，然后逐项send_keys，最后click提交按钮。这种做法的局限性非常明显：页面上必须恰好存在一个和接口字段对应的表单；如果目标接口是异步调用，页面根本不会准备表单控件；就算有表单，前端框架还可能在submit事件里做字段校验、输入过滤或者二次加密，我们通过send_keys写入的值会在前端逻辑里被改写或丢弃。此外，按钮click这个动作依赖元素可见、可点击，一旦前端把按钮隐藏，或者需要先满足某个状态才启用，click就会异常，整个“通过UI发POST”的方案就断在最后一步。这些限制本质上不是代码写得不好，而是WebDriver API的设计边界决定它只代理用户操作，不代理HTTP交互。

还有个细节容易被忽略：WebDriver在发起页面导航时，只保留了最基本的会话信息，不会把当前页面里JS内存中保存的临时状态一并传递。也就是说，即使你通过driver.get去提交一个完整URL，服务端收到的请求里，可能没有当前页面JS自行生成的签名、没有从localStorage里读取的token，也没有前端框架自动添加的X-Requested-With头。这在浏览器Network面板里反而不太容易一眼看出来，因为页面上每次点击引发的真实请求都带上了这些信息，而你手工构造的driver.get请求却没有。

2.2 浏览器上下文vs外部客户端：cookie、csrf-token与签名的归属问题

在决定用什么方案之前，先回答三个问题：需要提交的参数里，有没有一部分是在浏览器内存里现算出来的？有没有一部分要求请求头与页面同源，或必须由当前页面JS脚本自动带上？有没有可能服务端校验了HttpOnly cookie，而外部客户端根本拿不到这个cookie名？如果三个问题里有一个答案“有”，那纯外部客户端方案都要靠边站。

举个具体例子。某系统的登录接口，正常业务流程是先加载页面，页面里的JS会生成一个随机数并写入一个名为anti的cookie，之后所有提交请求都必须带上这个随机数。requests登录时虽然能拿到cookie里的值，但它不知道这个值是否与后续页面状态绑定。用post_json在浏览器上下文里发，请求发出时机恰好在页面加载后，JS早已把随机数写进cookie，fetch自动携带它，服务端校验才通过。这类问题并不罕见，尤其在一个系统里同时用到了HttpOnly cookie与普通业务cookie时，外部客户端通常会漏掉HttpOnly字段，导致登录后只要接口读取该cookie，请求就莫名其妙失败。

至于csrf-token，它的生成和校验大多依赖session与页面渲染，Selenium里的post_json可以做到每次提交前现取token，而外部客户端需要额外请求页面或接口才能模拟这个过程。更麻烦的是自定义加密签名。很多页面在提交敏感操作时，会先执行一段混淆过的JS，把几个字段拼接、做一次哈希或对称加密，再把结果作为sign参数放进请求体。如果这段运算使用到了页面内存里的某个随机密钥，那外部客户端的实现就完全沦为逆向工程，耗时且不稳定；而在Selenium上下文里执行一次真实fetch，等于把“运算过程”整个交给页面自己完成。三个归属问题合起来看就一句话：凡是“只有当前页面才能产生”的数据，都不能离开浏览器上下文。知道这个边界，再选封装方案就不会再选错。

2.3 三种封装方案对比：上下文内执行、请求层拦截、会话注入

常见有效措施归纳成三种。第一种是execute_async_script里跑fetch，这是最直接的方式，先打开页面建立上下文，再在页面上下文发POST，Cookie、Origin、Referer都由浏览器自动补齐；缺陷是如果接口要求修改Host头或者手动控制连接复用，fetch帮不上忙。第二种是通过Chrome DevTools Protocol的Network域拦截请求，适合在测试中断言某个POST是不是真的发出、参数是不是正确；缺点是回调是异步事件，拿不到同步返回值。第三种是requests预登录后，把cookie和token注入回Selenium，适合登录超复杂但业务请求简单的场景；缺陷是接口如果依赖页面内存中动态生成的参数，注入会话也解决不了。

三种方案在实际工程里不是互斥的。我通常的组合是：登录阶段用第三种，业务阶段用第一种，验证阶段用第二种。这样既绕开了WebDriver API不能直接发POST的边界，又把浏览器上下文完整保留在请求链路里。

3. 用execute_async_script封装post函数：可运行的Python示例

3.1 两个封装函数：post_json与post_form

先写最核心的封装。这里用Selenium 4的execute_async_script，配合页面里的fetch来发起POST请求。下面是一份可以直接放进工程里的Python代码：

from selenium import webdriver from selenium.webdriver.chrome.options import Options def create_driver(headless=False): options = Options() if headless: options.add_argument("--headless=new") options.add_argument("--no-sandbox") options.add_argument("--window-size=1920,1080") options.add_experimental_option("excludeSwitches", ["enable-automation"]) driver = webdriver.Chrome(options=options) driver.set_script_timeout(10) return driver def post_json(driver, url, payload, headers=None): script = """ const url = arguments[0]; const payload = arguments[1]; const headers = arguments[2] || {}; const callback = arguments[3]; fetch(url, { method: 'POST', headers: Object.assign({'Content-Type': 'application/json'}, headers), body: JSON.stringify(payload) }) .then(async res => { const data = await res.json().catch(() => null); callback([res.status, data]); }) .catch(err => callback([0, err.message])); """ return driver.execute_async_script(script, url, payload, headers) def post_form(driver, url, form_data, headers=None): script = """ const url = arguments[0]; const formData = arguments[1]; const headers = arguments[2] || {}; const callback = arguments[3]; fetch(url, { method: 'POST', headers: Object.assign({'Content-Type': 'application/x-www-form-urlencoded'}, headers), body: new URLSearchParams(formData).toString() }) .then(async res => { const data = await res.json().catch(() => null); callback([res.status, data]); }) .catch(err => callback([0, err.message])); """ return driver.execute_async_script(script, url, form_data, headers)

逻辑说明：这两个函数的核心是execute_async_script。Selenium执行异步脚本时，会将一个callback函数注入到arguments末尾，脚本结束前的任意时机调用它，都会把结果同步返回给Python端。post_json里用fetch发POST，然后用res.json()解析响应体；如果响应体不是合法JSON，res.json()会抛出异常，所以我在.then回调中嵌套了一层.catch(() => null)，保证遇到空响应或纯文本响应时，也能把状态码传回来，不至于让整个脚本卡死在Promise链上。post_form则把字典转成URLSearchParams，模拟标准的表单提交，OPPO很多老接口只认这种格式。

参数说明：driver.set_script_timeout(10)决定了execute_async_script最多等多少秒。如果你的POST接口响应很慢，把它调大到30或60，否则WebDriver会先抛出超时异常，哪怕接口在几秒后又发回了数据。headers参数会覆盖一部分默认头，注意Object.assign是浅合并，传入的headers里如果有Content-Type，会替换默认值，这样你可以发application/json;charset=utf-8这类变体。callback本身不需要出现在Python侧参数里，它是WebDriver自动追加的。

3.2 同步等待响应：execute_async_script的callback机制

有人会问，用execute_script不也能执行fetch吗？是的，能执行，但拿不到响应。execute_script是同步执行，它遇到fetch返回的Promise对象时，脚本不会等待Promise被resolve，而是立刻给Python端返回一个对象表示Promise。这个对象转换成Python数据结构后，常见的结果是一个只有[object Promise]字面量，或者干脆是None。你没法读它。即便你把fetch的返回值存到window上，然后用Python轮询读取，也要自己处理等待次数、并发覆盖、页面异常等额外问题。

execute_async_script把这件事处理得干净得多。它允许脚本在任意时间，通过回调函数把结果送出。WebDriver会一直等到超时时间结束，或者脚本主动调用了回调。所以封装post_json之后，Python调用方看到的就是一个同步函数：传入url、payload、headers，返回[状态码，响应体]。如果要拿到原始响应头，可以在.then里继续访问res.headers对象，把它转成普通对象后一并传入callback。不过注意，响应头里的部分字段如set-cookie可能被浏览器过滤，取不到时不要强行依赖它。

3.3 边界条件：非JSON响应、多层嵌套参数、跨域

一个容易翻车的地方是响应体解析。我习惯主动用.catch(() => null)兜底，但如果你明确知道接口一定返回JSON，可以把这层兜底去掉，解析失败时让catch分支上报err.message，这样便于排查到底是请求失败了还是响应结构变了。另一个边界是参数编码。post_form里的new URLSearchParams(formData).toString()只做一层扁平化编码，它会把嵌套对象转成[object Object]之类脏数据。如果你的业务接口需要提交数组或嵌套JSON，建议直接用post_json，把整个结构作为payload传入，而不是试图在form_data里做二次JSON序列化。如果必须走表单格式，先在外面把嵌套字段json.dumps成字符串，再塞进form_data字典。跨域的问题在第5章展开，这里只提一句：fetch运行的页面URL与目标接口URL只要不同源，浏览器就会先发预检。跨域接口能否调通，取决于服务端CORS策略，不取决于Selenium封装。

4. requests预登录并注入Selenium会话：混合方案详解

4.1 为什么需要外部预登录

第三章的方案已经能覆盖大部分“在Selenium里发POST”的需求，但还有一类场景它并不合适：登录过程本身非常不稳定。举例来说，某系统登录要经过扫码、滑块、短信验证三个环节，耗时一般10秒以上，偶尔验证码识别失败还要重来。如果把整个过程交给Selenium，每次跑业务脚本前都要重复一遍，浪费的时间远超接口请求本身。

更合适的做法是，把登录与业务请求解耦：先用requests写一个独立登录器，在外部完成认证，拿到会话凭据；再启动Selenium时，把这个会话凭据注入浏览器。浏览器启动后就已经是登录状态，可以直接访问页面并执行后续脚本。这种混合方案在数据采集类项目里几乎是标配，它对登录器本身的重试、超时、失败降级都很友好；requests做登录，可以轻易实现每次请求都调整UA、重试间隔和超时策略，而Selenium启动成本高，不适合反复销毁重建。

也要说实话：这套方案并非万能。如果目标接口的每个业务请求，都由页面内存里的JS现场生成动态签名，那即便把cookie注入浏览器，签名也还是生成不出来。所以混合方案解决的是“会话状态”的交接问题，不解决“页面执行环境”的问题。后者仍然要回到execute_async_script方案。

4.2 requests登录与cookie交接的完整代码

requests登录部分我通常封装成一个独立函数，返回一个已登录的requests.Session。下面这段是可用的骨架：

import requests from urllib.parse import urlparse def login_and_pick_cookies(login_url, login_data, timeout=10): session = requests.Session() session.headers.update({ "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36", }) resp = session.post(login_url, data=login_data, timeout=timeout) resp.raise_for_status() return session

这个骨架里做了两件容易被忽略的事：固定UA、设置超时。固定UA的意义在于，requests默认的python-requestsUA非常容易被服务端识别为脚本请求，某些系统会因此在登录成功后直接丢弃会话；设置超时是防止登录接口偶发5分钟才返回时，整个采集任务被卡死。如果你接的登录接口返回的是JSON，可以用session.post(login_url, json=login_data)代替data参数，这会自动设置Content-Type: application/json。

cookie交接时，有一个WebDriver的硬约束：必须在目标域名下先访问过一次页面，才能add_cookie。所以我下面这段注入函数，第一步总是driver.get：

def inject_cookies_to_driver(driver, login_url, session): domain = "." + urlparse(login_url).netloc.split(":")[0] root = f"{urlparse(login_url).scheme}://{urlparse(login_url).netloc}" driver.get(root) for name, value in session.cookies.get_dict().items(): driver.add_cookie({ "name": name, "value": value, "domain": domain, "path": "/", }) driver.refresh()

逻辑说明：这里domain加了前导点，例如.example.com，以便cookie在主域及所有子域生效；path设为/覆盖整个站点。driver.refresh()放在最后，是让浏览器在带着新cookie的状态下重新加载一次页面，这一步能触发页面里依赖cookie的初始化逻辑，比如把用户信息设置进前端状态。参数说明：如果目标站点只在当前精确域名下使用cookie，不带前导点更安全；domain错了，浏览器会拒收cookie，注入函数看着没报错，实际完全无效。

4.3 token与localStorage的交接

很多登录接口返回的不是cookie，而是{"access_token": "xxx"}这类数据。Selenium里如果用fetch去调业务接口，不一定每次都要显式带上token，更多情况是页面自己的JS从localStorage里读取token，再在请求拦截器里自动加进Authorization头。所以注入token和注入cookie是两件事，代码上一般不混在一起。

注入localStorage的方式如下，先打开业务页面，再执行一次JS写入，然后刷新页面让前端状态初始化：

login_result = login_session.post( "https://example.com/api/login", json={"account": "demo"} ).json() token = login_result["access_token"] browser.get("https://example.com/dashboard") browser.execute_script( "localStorage.setItem('access_token', arguments[0]);", token ) browser.refresh()

这里要留意localStorage是绑定Origin的，它的key-value只对当前域名生效。如果你的接口域名和页面域名不是同一个，那token要么放进cookie的domain参数，要么每次都在post_json里显式传Authorization。不要指望在a.example.com页面里写入的localStorage，能被api.example.com发请求时拿到，浏览器的隔离规则不允许。

4.4 混合方案完整流程与可复用性

把前面三段组合起来，整个流程是：requests登录获得Session对象；从Session里提取cookie字典；启动Selenium；跳转到目标站点的根路径；按domain+path添加cookie；如果有token，再写入localStorage；刷新页面；之后调post_json或让页面自身操作发起业务请求。这套流程我把登录、注入、业务三个环节拆成独立函数，好处是登录器出问题只改登录函数，业务脚本一行都不用动；将来如果某个站点换成扫码登录，也只需要换login_and_pick_cookies内部的实现。封装的价值不在于函数写得多花哨，而在于边界清楚、替换成本低。

5. 避坑指南：POST封装失败排查清单

5.1 现象：请求发出但服务端返回403，浏览器控制台里显示OPTIONS

用post_json调一个跨域接口时，如果服务端返回403，先在Network里看请求Method那一栏，很多时候显示的并不是POST而是OPTIONS。触发原因是浏览器跨域安全策略：对于跨域请求，只要存在自定义header、非简单Content-Type或非简单方法，浏览器都会先发送一个预检请求，预检通过后才发真实POST。服务端如果没正确响应预检，真实POST根本不会发到接口。

排查时先确认接口是否在目标页面的允许跨域名单里，也就是服务端是否返回了Access-Control-Allow-Origin对应头。如果服务端不做跨域处理，Selenium层面的任何封装都无能为力，只能把接口调用改成服务端转发，或者把页面与接口放在同一域名下。如果是同源接口却仍然触发预检，多半是自定义header惹的祸。把不需要的自定义头去掉，Content-Type统一下放到默认值，预检就会消失。还有一点，Access-Control-Request-Headers里如果出现请求headers之外的字段，也要顺手清理。

5.2 现象：登录接口正常，业务接口总是报CSRF token失效

这是混合方案里出现频率最高的问题。requests登录成功只代表会话建立，不代表拿到了页面后续将要使用的CSRF token。实际业务系统的csrf-token通常渲染在页面里的隐藏input或meta标签中，每次刷新页面都会变化。requests只拿到登录接口返回的那一次，Selenium浏览器再打开页面时，页面可能已经生成了新的token，两者不一致，服务端校验便失败。

解决思路是现取现用：每次真正发POST前，先从当前页面读取token，不要提前保存复用。读取方式我一般用一行execute_script：

token = browser.execute_script( "return (document.querySelector('meta[name=csrf-token]') || {}).content " "|| document.querySelector('input[name=_token]').value;" )

如果没有找到元素，脚本会抛JS的TypeError，所以更稳妥的写法是把选择器包裹成带返回值的三元表达式，找不到就返回空字符串，让Python端统一判断。

5.3 现象：add_cookie注入成功，页面刷新后仍是未登录状态

注入执行完没有任何报错，刷新页面后右上角仍然是“未登录”，这种情况我排查过不少于十次，最后原因大多落在两个点上。第一个是domain不匹配。Selenium要求先访问过目标域名才能add_cookie，但如果你访问的是www.example.com，cookie却设置为api.example.com，浏览器不会在后续页面请求中携带它。第二个是cookie名冲突，requests里的cookie名与页面已有cookie重名，add_cookie直接覆盖，却没覆盖掉HttpOnly属性，后续请求中的旧值继续生效。

排查时，在浏览器控制台执行document.cookie，和requests端session.cookies.get_dict()对比，缺一个就是注入链路某个环节错位。处理办法：注入前先清同名cookie，再add。domain去掉前导点，或者改成与当前页面完全一致的netloc，能规避大多数域不匹配问题。如果cookie本身设置了HttpOnly，requests拿得到但Selenium读不出，这时不要再依赖cookie，去主动请求数据，观察服务端是否在响应头里带Set-Cookie: HttpOnly标记。

5.4 现象：execute_async_script超时，但接口其实已经收到了请求

最典型的三个原因：第一个是脚本里fetch抛了异常，且异常发生在.then之前，Promise链没有后续处理，callback从未被调用；第二个是接口返回了非JSON响应体，res.json()抛出RejectedPromise，而.then里没有catch托底；第三个是页面在fetch执行期间被卸载，比如用户脚本里同时触发了页面跳转，回调在页面关闭后无处发声。

解决方向很明确：一是给脚本链路的末尾加.catch，回调无论如何都要执行一次；二是在res.json()外层再包一层catch，把解析失败吞掉；三是在调用post_json前，避免同页面里并发触发页面跳转。还可以把set_script_timeout调大，区分“接口慢”和“脚本卡死”两种情况。如果超时后，服务端日志显示请求已经收到且正常处理，那问题基本就是脚本侧回调没触发，优先检查catch分支。

5.5 现象：headless模式下POST参数丢失或接口表现不稳定

无头模式与有头模式在大多数情况下行为一致，但偶尔会遇到业务站点根据navigator.webdriver这类标志做反爬。webdriver标志一旦被检测，服务端可能故意返回不同的接口结果，甚至对参数做过滤。表现就是同样的post_json，有头模式正常，headless模式返回200但参数明显丢失，或者直接返回“visitor invalid”。

处理方式有几招：在create_driver里把excludeSwitches的enable-automation保留，同时固定窗口大小，有条件再设置--headless=new。新无头模式下，UA里的HeadlessChrome字样已经被去掉，检测失效概率低很多。还要注意，headless下如果窗口尺寸没设置，页面布局JS可能计算出异常值，间接污染表单字段，所以window-size不要省略。

6. 一个Mini案例：用CDP断言验证post_json，别停在“接口能通”

封装函数写好后，如果只看到接口返回200，其实并不能证明POST参数和你想的一致。验证方式是用CDP监听Network.requestWillBeSent事件，捕获真实请求体再比对。下面这段代码能直接跑起来看效果。

from selenium import webdriver from selenium.webdriver.chrome.options import Options captured = {} def capture(params): req = params.get("request", {}) if req.get("method") == "POST": captured["url"] = req["url"] captured["body"] = req.get("postData", "") browser = webdriver.Chrome(options=Options()) browser.get("http://localhost:8000/login") browser.add_cdp_listener("Network.requestWillBeSent", capture) browser.execute_cdp_cmd("Network.enable", {}) status, body = post_json(browser, "http://localhost:8000/api/save", {"title": "cdp-test", "range": 5}) assert captured["url"].endswith("/api/save") assert "\"title\":\"cdp-test\"" in captured["body"] print("POST参数核对通过")

这段代码的关键在于，CDP事件在浏览器真正发出请求前触发，所以捕获到的postData就是实际打到服务端的请求体。用它与Python端传入的payload比对，能在第一时间发现编码不一致、字段缺失、多字段三类问题。从那以后，我每次新接口接入都强制走一遍这个流程——构造payload、发一次post_json、用CDP断言核对postData，一致才敢往下写。这个习惯帮我挡掉了很多隐藏很深的边界参数错误。希望帮到你。

本文还有配套的精品资源，点击获取