在python中使用requests库设置请求头需通过headers参数传入字典，该方法适用于GET和POST请求，可自定义User-Agent、Content-Type等字段以模拟浏览器、传递认证信息或指定数据格式；使用Session对象能实现请求头持久化、自动管理Cookie及复用TCP连接，提升效率与代码可维护性；实际应用中需注意请求头字段准确性、避免敏感信息明文传输，并结合API文档正确配置内容类型与认证方式，确保请求合法有效。
在Python中使用
requests
库设置请求头（headers）非常直接，核心就是通过
headers
参数传递一个字典。这个字典的键是请求头的名称（例如
User-Agent
、
Content-Type
），值则是对应的字符串。无论你是发起GET还是POST请求，这个方法都通用，它能让你精细地控制发送到服务器的http请求的元数据。
在
requests
中自定义请求头，其实就是给
get()
、
post()
等方法传入一个
headers
参数。这个参数期待一个Python字典，字典的键是HTTP请求头的字段名，值则是该字段的对应内容。
import requests # 定义你想要发送的请求头 custom_headers = { 'User-Agent': 'Mozilla/5.0 (windows NT 10.0; Win64; x64) AppleWebKit/537.36 (Khtml, like Gecko) Chrome/91.0.4472.124 Safari/537.36', 'Accept-Language': 'zh-CN,zh;q=0.9,en;q=0.8', 'Referer': 'https://www.google.com/' # 模拟从Google跳转过来 } url = 'http://httpbin.org/headers' # 一个测试URL，会返回你发送的请求头 # 发送GET请求并带上自定义请求头 response_get = requests.get(url, headers=custom_headers) print("GET 请求头响应:") print(response_get.JSon()) # 发送POST请求并带上自定义请求头和一些数据 post_data = {'key': 'value'} response_post = requests.post(url, headers=custom_headers, data=post_data) print("nPOST 请求头响应:") print(response_post.json())
这段代码展示了最基本的用法。
custom_headers
字典里的每一个键值对都会被添加到HTTP请求的头部。服务器收到请求后，就能识别这些自定义信息。这在很多场景下都非常有用，比如模拟浏览器行为、传递认证令牌、指定内容类型等等。
为什么说自定义requests请求头在某些场景下是不可或缺的？
自定义请求头的重要性，往往体现在与服务器的“对话”中。我们知道，HTTP协议不仅仅是传输数据，它还承载了大量关于请求和响应的元信息，这些信息就通过请求头和响应头来传递。在我看来，有几个场景是特别需要我们去主动设置请求头的：
立即学习“Python免费学习笔记（深入）”；
首先，模拟浏览器行为。很多网站为了防止爬虫或者识别客户端类型，会检查
User-Agent
头。默认情况下，
requests
库会发送一个类似
python-requests/2.x.x
的
User-Agent
。这在很多网站看来，就是“非正常访问”，轻则返回不完整内容，重则直接拒绝请求或封禁IP。这时候，我们通常会设置一个主流浏览器的
User-Agent
来“伪装”自己。有时，甚至还需要设置
Accept-Language
来指定期望的语言，或者
Referer
来模拟是从某个页面跳转过来的，这能让我们的请求看起来更“自然”。
其次，API认证。现在很多restful API都采用基于Token的认证方式，比如OAuth 2.0的Bearer Token。客户端需要将这个Token放在
Authorization
请求头中发送给服务器，服务器才能验证请求的合法性。没有这个头，或者头内容不正确，API调用就会失败。这几乎是所有需要登录后才能访问的API的标配。
再者，内容协商与数据提交。当我们需要向服务器提交JSON或xml数据时，通常需要设置
Content-Type
头来告诉服务器请求体的数据格式，比如
application/json
或
application/xml
。如果服务器期望JSON而你没有设置这个头，或者设置成了错误的类型，服务器可能无法正确解析你的请求体，导致数据提交失败。同样，
Accept
头可以告诉服务器我们期望接收什么类型的数据。
最后，缓存控制和条件请求。虽然不常用，但在一些高级场景中，我们可能需要通过
if-None-Match
或
If-Modified-Since
等头来配合服务器的缓存机制，实现条件式请求，避免重复传输未修改的数据，提高效率。
可以说，自定义请求头是我们在网络请求中与服务器进行“高级沟通”的必备工具。它允许我们更精细地控制请求行为，以适应各种复杂的网络环境和服务器要求。
使用requests.Session管理请求头有什么优势？
在实际开发中，尤其是当我们需要向同一个服务器发起一系列请求时，使用
requests.Session
对象来管理请求头，会带来显著的优势。这不仅仅是代码组织上的便利，更涉及到性能和请求行为的一致性。
最直接的优势是请求头的持久性。如果你在多个请求中需要发送相同的请求头（比如认证Token、
User-Agent
），而不用
Session
，你就得在每个
requests.get()
或
requests.post()
调用中重复传入
headers
字典。这不仅冗余，而且容易出错。
Session
对象允许你设置一次默认的请求头，之后通过该
Session
对象发出的所有请求都会自动带上这些头，除非你特意在某个请求中覆盖它们。
import requests # 创建一个Session对象 session = requests.Session() # 为Session设置默认请求头 session.headers.update({ 'User-Agent': 'MyCustomApp/1.0', 'Authorization': 'Bearer YOUR_AUTH_TOKEN_HERE', 'Accept': 'application/json' }) # 通过Session发起请求，这些请求会自动带上上述headers response1 = session.get('http://httpbin.org/headers') print("Session 请求 1 响应:") print(response1.json()) # 即使是另一个请求，也依然带上了Session的headers response2 = session.post('http://httpbin.org/headers', data={'foo': 'bar'}) print("nSession 请求 2 响应:") print(response2.json()) # 你也可以在单个请求中覆盖Session的默认头 response3 = session.get('http://httpbin.org/headers', headers={'User-Agent': 'TemporaryAgent/1.0'}) print("nSession 请求 3 (覆盖User-Agent) 响应:") print(response3.json())
除了请求头，
Session
对象还能自动处理Cookie。它会在会话生命周期内自动存储和发送从服务器接收到的Cookie，这对于需要维护登录状态的网站爬取或API交互至关重要。你无需手动解析
Set-Cookie
响应头并将其添加到后续请求的
Cookie
请求头中，
Session
会帮你搞定这一切。
此外，
Session
对象还提供了TCP连接复用的性能优势。当通过同一个
Session
对象向同一个域名发起多个请求时，
requests
会尝试复用底层的TCP连接。这意味着减少了每次请求时建立新连接的开销（如TCP三次握手和TLS握手），从而提高请求速度和效率，尤其是在高并发或长连接场景下。
总的来说，
requests.Session
是处理一系列相关请求的利器。它简化了代码，提高了效率，并且让请求行为更具一致性，是编写健壮网络客户端代码的推荐做法。
设置请求头时常遇到的挑战和一些实践建议
在设置
requests
请求头时，虽然概念简单，但在实际操作中还是会遇到一些挑战，并有一些值得注意的实践点。
一个常见的挑战是请求头字段的准确性。HTTP请求头字段名虽然通常是大小写不敏感的，但为了代码的可读性和与规范的一致性，最好还是遵循标准的驼峰命名法（如
User-Agent
、
Content-Type
）。更重要的是，字段值必须符合服务器的预期。比如，
Content-Type
的值如果是
application/json
，那么你的请求体就必须是合法的JSON字符串。如果内容不匹配，服务器会返回400 Bad Request之类的错误。我曾经就因为一个字符的差异，导致API接口一直报错，排查了半天才发现是
Content-Type
写成了
application/json;charset=UTF-8
，而服务器只认
application/json
。
另一个需要注意的点是默认请求头的覆盖与合并。
requests
库本身会发送一些默认的请求头，例如
Connection: keep-alive
。当你传入自定义
headers
字典时，如果你的字典中包含了
requests
默认会发送的同名字段，你的值会覆盖掉默认值。如果你的字典中没有，默认值会保留。这通常是期望的行为，但有时可能导致意外。例如，如果你想在已有的
User-Agent
基础上追加一些信息，而不是完全替换，就需要先获取默认的
User-Agent
再进行拼接，但这通常不建议，直接完全替换更清晰。
对于
User-Agent
的设置，虽然模拟浏览器能解决很多问题，但过度依赖单一的
User-Agent
也可能导致IP被封禁。一些更高级的反爬机制会检测
User-Agent
与请求模式（如请求频率、请求路径）是否匹配。在更复杂的场景下，你可能需要维护一个
User-Agent
池，并随机选择使用，甚至模拟更完整的浏览器指纹（如
Accept
、
Accept-Encoding
、
Accept-Language
等一系列头）。但这已经超出了简单设置请求头的范畴，属于反爬策略了。
安全考量也不容忽视。在请求头中传递敏感信息（如认证Token）时，务必确保连接是HTTPS加密的。HTTP协议是明文传输的，如果通过HTTP发送认证信息，这些信息在网络传输过程中可能被截获。此外，不要在客户端代码中硬编码敏感的API密钥或认证Token，而是应该通过环境变量、配置文件或更安全的密钥管理服务来获取。
最后，错误处理。当服务器返回非2xx状态码时，检查响应头和响应体中的错误信息通常能帮助你快速定位问题。很多API会在错误响应中包含
Content-Type: application/json
，并在JSON体中提供详细的错误描述。学会利用这些信息，而不是盲目地修改请求头，能大大提高调试效率。
总之，设置请求头是一个看似简单实则需要细致考量的工作。理解HTTP协议规范，结合服务器的API文档，并注意实践中的常见陷阱，才能让我们的网络请求更加高效和稳定。
评论（已关闭）
评论已关闭