Python爬虫怎么处理复杂的POST请求_利用Python模拟Form表单提交

正确构造带文件上传的 multipart/form-data 请求需用 requests.Session() 管理 Cookie，data 传文本字段、files 传文件元组，由 requests 自动设 boundary 和 Content-Type；CSRF Token 需先 GET 提取再即时使用。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

怎么构造带文件上传的 multipart/form-data POST 请求

直接调用 requests.post(url, data=...) 大概率会失败。原因很简单：这个方法默认发送的是 application/x-www-form-urlencoded 格式，而包含文件上传的表单，其内容类型必须是 multipart/form-data，并且需要一个由库自动管理的边界（boundary）。

正确的做法，是将普通字段和文件字段分开处理：data 参数用于存放纯文本字段，files 参数则专门用于文件字段。这样一来，requests 库就会自动拼接 boundary、并设置正确的 Content-Type 请求头。

• 普通字段：比如 username、csrf_token，直接写入 data 字典，值为字符串即可。
• 文件字段：比如 a vatar，必须写入 files 字典，并且值需要是一个三元组：('filename.jpg', open('path.jpg', 'rb'), 'image/jpeg')。
• 关键提醒：千万不要手动设置 Content-Type 请求头。一旦手动指定，requests 就会跳过自动生成 boundary 的步骤，直接导致服务端解析失败。
• 资源管理：文件句柄记得用 with 语句打开，或者确保后续调用 close() 方法。requests 库不会帮你关闭文件。

如何处理带 CSRF Token 的表单提交

很多网站的表单里都藏着“暗桩”——一个名为 csrf_token 的隐藏字段。这个值可不是固定的，必须先用 GET 请求获取页面，然后用正则表达式或者 BeautifulSoup 把它“挖”出来，再塞进后续的 POST 数据里。

漏掉这个 token，或者复用了过期的旧 token，是导致 403 或 422 错误的常见原因，尤其是在登录、发表评论这类敏感操作中。

立即学习“Python免费学习笔记（深入）”；

• 第一步，使用 requests.get(url) 获取页面的 HTML 源码。
• 第二步，用 re.search(r'name="csrf_token"\s+value="([^"]+)"', html_text) 或者 soup.find('input', {'name': 'csrf_token'})['value'] 提取出 token 值。
• 第三步，提取后立刻用于下一次 POST 请求，不要缓存超过 1 分钟，因为这类 token 通常都有时效性。
• 额外情况：有些站点会用 X-CSRFToken 这样的请求头来传递 token。这时就需要从 Set-Cookie 响应头或者响应体中提取值，然后手动加到 headers 字典里。

POST 请求里该用 data 还是 json 参数

这取决于目标接口的设计。最可靠的方法是查看接口文档，或者打开浏览器的开发者工具，在「Headers」标签页下查看「Request Payload」部分。格式一旦不对，服务端可能根本收不到你发送的字段。

• 传统表单提交（Content-Type: application/x-www-form-urlencoded）→ 使用 data=dict(...)，requests 会自动将其编码成 a=1&b=2 的格式。
• 现代 API 接口（Content-Type: application/json）→ 使用 json=dict(...)，requests 会自动序列化字典并设置正确的请求头。
• 避免冲突：同时混用 data 和 json 参数会导致冲突，requests 可能会报错，或者静默忽略其中一个。
• 特殊情况：如果必须发送 JSON 数据，但服务端（比如一些老旧系统）不识别 application/json 请求头，可以手动组合：data=json.dumps(...) 并加上 headers={'Content-Type': 'application/json'}。

为什么用 Session 而不是反复 new requests

核心原因在于 Cookie 的维持。像 sessionid、login_token 这类关键 Cookie 需要自动携带。如果每次 POST 都新建一个请求对象，就等于每次都在开一个新的“隐身窗口”，之前的登录状态全部丢失。

• 标准做法：统一使用 s = requests.Session() 创建一个会话对象，后续所有的 s.get() 和 s.post() 调用都会自动共享 Cookie。
• 便捷性：登录成功后，后续的请求就无需再手动处理 Cookie，Session 对象会自动附带。
• 注意边界：有些网站的 Cookie 是通过 Ja vaScript 动态写入的，单纯的 requests 请求无法获取。遇到这种情况，可能需要切换到 Selenium，或者深入分析 JS 逻辑来模拟生成。
• 重定向处理：Session 对象本身不会自动处理重定向后的 Cookie 更新，但好在默认的 allow_redirects=True 参数已经能覆盖绝大多数场景。

说到底，一个 POST 请求能否成功跑通，关键往往不在于 POST 本身，而在于前序动作：你是否拿到了最新的 token？Cookie 是否持续有效？multipart 的边界有没有被手动破坏？这些细节一旦出错，服务端可能连错误日志都不会记录——因为它根本就没能成功解析到你发送的字段。