verify=false 使 requests 跳过全部 ssl 证书验证（含链追溯、域名匹配、有效期及吊销检查），连接直连但完全放弃安全防护，仅限本地调试；生产环境禁用。
直接说结论：这不是爬虫代码写错了，而是你的 Python 环境无法信任目标网站的 SSL 证书。根本原因通常不在网站端，而在你本地——证书信任链断裂、根证书过期、或系统/Python 安装没带完整 CA 证书包。
requests.get() 中 verify=False 是什么效果
它让 requests 库跳过全部 SSL 证书验证步骤，包括证书链追溯、域名匹配、有效期检查和吊销状态查询。连接会直接建立，不校验证书真伪。
- ✅ 快速见效：加一个参数，报错消失，数据立刻能拿到
- ❌ 完全放弃安全防护：中间人攻击（比如公司代理、公共 Wi-Fi 下的恶意设备）可轻松劫持、篡改甚至伪造响应内容
- ⚠️ 默认触发
InsecureRequestWarning警告；若用urllib3.disable_warnings()抑制，警告没了但风险照旧 - ? 生产环境、涉及任何用户数据或业务逻辑的请求，绝对不要用
verify 参数支持的三种取值及适用场景
verify 不只是 True 或 False，它实际接受三种类型：
-
True（默认）：使用系统或certifi提供的根证书包验证，路径由certifi.where()返回 -
False：彻底关闭验证，如上所述，仅限本地调试 -
/path/to/cert.pem或/path/to/certs/：指定自定义证书文件或目录，适用于内网服务、自签名证书或私有 CA 场景
例如对接测试环境的 HTTPS API：requests.get("https://api-dev.internal", verify="/etc/ssl/certs/internal-ca.pem")
为什么 certifi.where() 常是更稳妥的起点
很多报错其实源于 Python 自带的证书包陈旧或缺失，尤其 macOS 上从 python.org 下载的安装包、或某些 Linux 容器镜像。而 certifi 是 requests 官方维护的最新 CA 证书集合，更新及时、跨平台一致。
- 先执行：
pip install --upgrade certifi - 然后显式指定：
requests.get(url, verify=certifi.where()) - 如果仍失败，说明问题不在证书包本身，而是目标站点用了非标准证书（如自签名、企业内网 CA），这时才考虑自定义路径或排查服务器配置
容易被忽略的关键点
时间不同步会导致证书“看起来已过期”——哪怕证书本身有效，只要本机系统时间偏差超过几十秒，SSL 验证就会失败。检查并同步 NTP 时间比反复改代码更管用。
另外，verify=False 对 Session 对象同样生效，但别误以为设一次就全局生效：每个新 Session() 实例都需单独设置，且不能覆盖已有实例的行为。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
