python警告虽不中断程序，但默认被忽略，需主动配置如-w default或warnings.simplefilter("error")使其可见，否则升级后易引发兼容性故障。
Python 警告（Warning）不是错误，但会被默认忽略
Python 的 warnings 模块发出的警告不会中断程序，也不触发异常，所以很多人压根没意识到自己代码里正狂刷 DeprecationWarning 或 FutureWarning。默认情况下，Python 只对 UserWarning 和 SyntaxWarning（在交互式环境）显示一次，其余大多被静默吞掉。
常见错误现象：pip install 时一堆黄色警告、pandas 读 CSV 提示 FutureWarning: Passing list-likes to .loc is deprecated，但脚本照常跑完——这不代表没问题，只是“暂时没崩”。
- 使用场景：升级 Python 版本、更新第三方库（如从 pandas 1.x 升到 2.x）、用实验性 API（如
asyncio.run()早期版本）时，警告是第一波兼容性信号 - 参数差异：
warnings.filterwarnings()的action参数决定行为，"error"会把警告转成异常，"ignore"彻底屏蔽，"always"每次都打印（适合调试） - 性能影响极小，但频繁调用
warnings.warn()在 tight loop 里可能有微小开销；兼容性上，不同 Python 小版本对同一警告的触发时机可能不同（比如 3.11 对datetime.utcfromtimestamp()的警告比 3.9 更激进）
如何让警告真正可见——不只是靠 print
靠肉眼扫终端输出不可靠，尤其 CI/CD 环境或日志聚合系统里，警告容易被淹没。必须主动控制警告的捕获和呈现方式。
- 开发期：启动 Python 时加
-W default（例如python -W default script.py），强制所有警告以标准格式输出，包括原本被忽略的DeprecationWarning - 测试中：用
pytest时加--disable-warnings是错的——应该用--capture=no -W error::DeprecationWarning把特定警告当错误拦住 - 线上服务：别用
logging.captureWarnings(True)直接塞进 root logger，容易污染日志层级；更稳妥的是单独配一个warningshandler，把Warning类型消息打到独立文件或监控通道 - 注意：
filterwarnings("ignore", category=FutureWarning)看似省事，实则掩盖技术债；应只针对已知、确认无害且短期内无法修复的警告临时压制
区分 Warning 类型的关键不是名字，而是触发位置和生命周期
DeprecationWarning 和 PendingDeprecationWarning 听起来像兄弟，但 Python 解释器对待它们天差地别：前者默认不显示（除非你显式开启），后者默认就显示——因为它是“再不改就要炸”的倒计时。
立即学习“Python免费学习笔记（深入）”；
-
RuntimeWarning：运行时语义可疑但未必错，比如numpy数组除零产生inf，或datetime时区处理含糊 -
UserWarning：库作者留给使用者的柔性提示，比如matplotlib检测到字体缺失时发这个，它默认显示，适合做用户可感知的友好提醒 -
ResourceWarning：资源泄漏线索，比如文件对象没 close 就被 gc 回收，仅在-X dev或python -W default下活跃，生产环境容易漏看 - 自定义警告类必须继承
Warning或其子类，否则filterwarnings无法匹配；直接 raiseWarning("msg")是无效的，会报TypeError
在 CI 中把警告当质量红线来卡
很多团队只检查 test 是否 pass，却放任 warning 滋生，结果上线后某次 Python 升级直接让 DeprecationWarning 变成 AttributeError。
- GitLab CI / GitHub Actions 中，在
python -m pytest命令后追加2>&1 | grep -q "warning" && exit 1 || true是懒办法，且漏掉非 stderr 输出；正确做法是用pytest --strict-markers --warn-default配合warnings插件 - 静态检查工具如
pylint能发现部分硬编码警告（如assert False），但对动态warnings.warn()无能为力；真正可靠的是运行时拦截——在测试入口加warnings.simplefilter("error", DeprecationWarning) - 容易踩的坑：Docker 容器内 Python 默认不显示
DeprecationWarning，因为sys.warnoptions为空，必须在 CMD 前显式传-W default，否则 CI 里永远看不到警告
警告本身不崩溃，但它的沉默比报错更危险——尤其当你依赖的库悄悄改了行为，而你的测试又没覆盖那个分支时。
