用 r.headers['content-type'] 直接读取响应头中的 content-type，r.headers 是大小写不敏感的 caseinsensitivedict，存储服务器返回的响应头，而非请求头。
怎么用 requests 读取响应头里的 Content-Type
响应头不是响应体，不能从 r.text 或 r.json() 里扒——得直接查 r.headers 这个类字典对象。它大小写不敏感，但键名默认是首字母大写的格式（比如 'Content-Type'），实际用 r.headers['content-type'] 也能取到，不过建议统一用标准写法避免混淆。
常见错误：把 r.request.headers 当成响应头——那是你发出去的请求头，不是服务器返回的。
-
r.headers是服务器返回的响应头，类型是CaseInsensitiveDict - 想检查是否压缩了，看
r.headers.get('content-encoding')，值可能是'gzip'或'br' - 如果接口返回 JSON 但
Content-Type缺失或写错（比如写成'application/json; charset=utf8'少了个横杠），r.json()可能抛JSONDecodeError，别急着改代码，先确认头里到底写了啥
怎么在 requests.get() 里加自定义请求头
直接传 headers= 参数就行，值是普通 Python 字典。注意：一旦指定，requests 就不会自动补 User-Agent 等默认头——你给啥就是啥，没给的就真没了。
典型翻车场景：爬虫被拒，查日志发现服务端只收到空 User-Agent，因为本地字典里漏写了这一项；或者写了 'user-agent' 小写键，虽能工作但可读性差，建议全用首字母大写风格。
立即学习“Python免费学习笔记（深入）”；
- 必须显式带上
'User-Agent'，否则很多站点直接 403，例如：{'User-Agent': 'Mozilla/5.0 (X11; Linux x86_64) ...'} - 带认证时用
'Authorization'，值通常是'Bearer xxx'或'Basic base64string'，别手抖多加空格 - 如果要复用一套头多次请求，定义成变量再传，别每次现场拼字典，容易漏键或大小写不一致
headers 里设 Accept 和 Accept-Encoding 有啥实际影响
这两个头不是摆设。Accept 告诉服务器“我要什么格式”，服务器可能据此切换返回内容（比如 application/json vs text/html）；Accept-Encoding 则决定要不要压缩传输，影响响应体积和解码开销。
容易忽略的是：requests 默认发 Accept-Encoding: gzip, deflate，但某些老 API 或内网服务不支持压缩，会直接返回乱码或 500。这时候得手动关掉：headers={'Accept-Encoding': 'identity'}。
-
Accept: application/json可能让后端跳过模板渲染，直出 JSON，省带宽也省解析时间 - 设
Accept: */*是默认行为，但有些接口对通配符响应更简陋，明确声明反而更稳 - 如果响应体很大（比如文件下载），又不想让 requests 自动解压，就设
Accept-Encoding: identity，再自己处理r.content
用 session 管理请求头时要注意啥
用 requests.Session() 可以一次设置、多次复用头，但得小心“头被意外覆盖”——后续单次请求如果再传 headers= 参数，会完全替换 session 级别的头，不是合并。
比如 session 设了 User-Agent，某次请求又传了个不含 User-Agent 的字典，那这次请求就真没 UA 了。这不是 bug，是 requests 的明确设计。
- 想追加而非覆盖，得手动合并：
new_headers = {**session.headers, **extra_headers} - 登录后需要带
Cookie，session 会自动维护，但如果你在单次请求里传了headers，其中又含Cookie，就会顶掉 session 自己存的，导致后续请求失效 - 调试时用
session.headers.update(...)比反复传参更可控，但记得别在多线程里共用同一个 session 实例
r.request.headers 和 r.headers 对着看两眼，比查文档快。 
