requests API调用中使用verify=True参数的意义是什么？

• 从传输层拦截中间人攻击：SSL/TLS协议设计的核心目的从来不是单纯做传输加密，最关键的能力是确认你正在通信的对端，就是你预期要访问的目标服务器。开启verify=True时，requests会对照内置的可信根证书列表，逐一校验对端出示的证书是否由可信机构签发、绑定的域名是否与当前访问的地址匹配、是否在有效期内、是否在官方吊销列表中，只要任意一项校验不通过，就会直接抛出SSL错误终止请求，从根源上避免恶意网络节点截获、篡改你传输的token、密钥、业务数据。
• 避免无感知的配置错配：实际开发中经常遇到DNS解析异常、服务临时切到测试环境、内网配置写错的场景，如果使用verify=False，requests不会对对端身份做任何检查，你可能连续数天把生产环境的业务数据传到错误的测试服务器上都毫无察觉；而开启verify=True后，只要对端的证书和预期不匹配，请求会直接报错中断，不会出现静默的跨环境数据错传问题。

你之前误以为该参数和自签名证书生成有关，其实是对参数功能边界的误解：

• verify参数的全流程逻辑都围绕校验对端身份展开，完全不涉及本地生成、签发证书的相关能力。
• 如果需要访问部署了自签名证书的内部服务，正确做法不是关闭校验设置verify=False，而是将该自签名证书的文件路径传入verify参数——requests会把这个证书加入本次请求的可信列表，在保留完整身份校验能力的前提下正常完成访问，不会牺牲传输安全性。
• 不少开发者遇到证书报错就直接设置verify=False图省事，本质是完全关闭了对端身份校验流程：不管对面是恶意网络节点、配置错误的服务器还是劫持流量的代理，requests都会照常完成请求，这种操作仅适合本地临时调试，绝对不能在生产环境使用。

• verify=True（库默认值）：调用系统/requests内置的可信根证书库完成全量证书校验，是生产环境必须保持的配置
• verify=本地证书文件路径：在通用校验逻辑的基础上，额外信任指定路径的证书文件，适用于自签名证书的内网、测试环境访问
• verify=False：完全跳过所有对端证书校验流程，不对证书的有效性、匹配度做任何检查，仅可作为临时调试的兜底选项

内容的提问来源于stack exchange，提问作者phoenix97