Python warnings 规则顺序：先设置 error，为什么后来的一条 ignore 让测试通过了
测试启动时把自家组件的告警设成错误，希望升级依赖后及时失败。后来公共初始化代码又加了一条忽略所有告警，原本该失败的样本突然通过。过滤系统不会把匹配规则全部执行一遍，也不会自动选择类别最具体的规则；排在前面的第一条匹配规则就决定处理动作。
warnings.simplefilter 默认把新规则放到列表前面。因此后来加入的宽泛规则可能先命中，让原来的 error 没有机会参与判断。排查时既要看动作和类别，也要看最终顺序，不能只搜索代码中是否出现了把告警升级为错误的那一行。
可直接运行的对照实验
下面保存为 demo.py，在 Python 3.12 单线程进程中运行。定义独立的 SchemaWarning 类，让样本不依赖任何第三方包。两次实验使用相同告警，唯一变量是第二条宽泛规则是否追加到末尾；with 将修改限制在实验范围内。
AI概念插图：前后排列的过滤关卡决定同一信号最终进入哪个处理入口。图片不是运行截图，也不表示实测性能。
import warnings
class SchemaWarning(UserWarning):
pass
def check(append):
with warnings.catch_warnings(record=True) as captured:
warnings.resetwarnings()
warnings.simplefilter("error", SchemaWarning)
warnings.simplefilter("ignore", Warning, append=append)
try:
warnings.warn("field was renamed", SchemaWarning)
except SchemaWarning:
outcome = "error"
else:
outcome = "ignored"
assert captured == []
return outcome
assert check(False) == "ignored"
assert check(True) == "error"
print("prepend:", check(False))
print("append:", check(True))
with warnings.catch_warnings(record=True) as captured:
warnings.simplefilter("always", SchemaWarning)
for _ in range(2):
warnings.warn("same test signal", SchemaWarning)
assert len(captured) == 2
assert all(item.category is SchemaWarning for item in captured)
print("always captured:", len(captured))追加参数控制位置，不改变匹配范围
第一行是 prepend: ignored，说明默认新增的 ignore 已站到最前面。第二行是 append: error，说明 append=True 把宽泛忽略留在末尾，前面针对 SchemaWarning 的 error 先匹配。这里不是系统自动偏爱子类，而是代码安排了规则顺序。
忽略 Warning 基类会覆盖其子类，所以它能够匹配 SchemaWarning。如果改成只忽略另一种无关类别，就不会形成同样冲突。定位实际项目时，可以打印规则的动作与类别来检查范围；不要在日志中只记一串动作名称，否则不同类别和消息条件会被混在一起。
让测试证明告警确实被发出
record=True 把可记录告警放入列表，但它不会把已经被 ignore 丢掉的告警找回来，也不会阻止 error 抛出异常。因此前两组记录列表都为空，却代表两种完全不同的结果。代码额外检查 outcome，避免把“没有记录”误判为“没有问题”。
第三组使用 always，明确让两个相同告警都进入记录，然后验证数量和类别。这样可以区分代码没走到告警路径，与告警确实发出但被过滤掉。若测试目标是重复抑制行为，应另建样本控制位置和注册表状态，不要把它夹在本次规则顺序实验中。
公共库不宜随意覆盖调用方政策
在自家应用入口统一决定告警政策，比每个辅助模块导入时都插入一条全局忽略更容易维护。确实需要临时压制一段已知告警时，应缩小类别、消息或模块范围，并在有限作用域内完成；宽泛 ignore 很容易让以后出现的新告警一起消失。
本例在每个隔离作用域里调用 resetwarnings，是为了建立可重复的实验起点，不是建议公共库清除用户传入的启动选项。真实测试框架可能已经按命令行配置过滤器，清空它们会改变使用者明确选择的行为。修复顺序问题时应保留必要的既有规则。
Python 3.12 的 catch_warnings 会改动进程共享状态，本例不提供多线程隔离保证。更高版本的并发行为还涉及运行时配置，应查对应版本文档。验收时记录解释器版本、规则添加顺序、实际异常与记录数量，才能证明测试为何通过，而不只看退出码。
资料核对日期：2026年10月2日（北京时间）。代码在 CPython 3.12.14 中独立运行。
