Python第三方库用系统CA替代certifi CA：修改全局SSL上下文是否为不良实践？

这种做法属于不推荐的不良实践，核心原因如下：

• 破坏封装与兼容性：第三方库的全局变量属于内部实现细节，并非公开API。库作者完全可能在后续版本中变更这个变量的命名、类型或用途，直接修改会让你的代码在库升级后出现莫名其妙的报错，兼容性毫无保障。
• 引入全局副作用：修改全局SSL上下文会影响该库所有使用这个上下文的功能——包括你没关注到的内部模块调用。如果库的某些逻辑依赖certifi的CA证书集合，强行替换成系统CA可能导致部分服务的证书验证失败，引发难以排查的问题。
• 可维护性极差：这种全局修改属于“隐式变更”，其他维护代码的开发者很难发现这个改动，后续排查SSL相关问题时会浪费大量时间。

更稳妥的替代方案 #

• 优先使用官方配置：先查第三方库的文档，绝大多数提供网络请求功能的库都会支持通过参数、配置项或环境变量来自定义SSL上下文，这才是合规的做法。
• 局部替换而非全局修改：如果只需要在特定场景下使用系统CA，创建独立的SSL上下文并传递给对应的方法即可，避免影响全局。示例：

  import ssl
  custom_ctx = ssl.create_default_context()
  package.specific_function(ssl_context=custom_ctx)
  

• 调整certifi相关环境变量（迫不得已时）：如果库硬绑定了certifi，可以尝试设置REQUESTS_CA_BUNDLE（针对基于requests的库）这类环境变量，让certifi指向系统CA证书文件，这种方式比直接修改全局变量更具可追溯性。

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