正确构造带文件上传的 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 的边界有没有被手动破坏？这些细节一旦出错，服务端可能连错误日志都不会记录——因为它根本就没能成功解析到你发送的字段。
