可通过 sys.flags.optimize 值判断优化模式：0 为正常（assert 有效），1 或 2 表示 -o 或 -oo 模式（assert 被编译期彻底移除，条件表达式不求值）；设计为移除而非跳过是为了零运行时开销。
因为 Python 解释器在 -O 或 -OO 模式下会直接从字节码中移除所有 assert 语句，不是“跳过执行”，而是压根不编译进去。
怎么确认当前是否处于优化模式？
运行时 sys.flags.optimize 的值决定行为：
• 值为 0：正常，assert 有效
• 值为 1（-O）或 2（-OO）：所有 assert 被剔除，连条件表达式都不求值
可在代码开头加 print(sys.flags.optimize) 快速验证；也可用命令行检查：python -c "import sys; print(sys.flags.optimize)"
为什么设计成“彻底移除”而不是“静默跳过”？
这是明确的性能取舍：
• -O 模式本意是减小字节码体积、提升启动速度，移除 assert 是编译期动作，不产生任何运行时开销
• 如果只是“不抛异常但还求值”，就违背了优化初衷——比如 assert expensive_check() 在 -O 下本该零成本，若保留求值就失去意义
• -OO 还额外丢弃 __doc__ 字符串，说明这是激进的发布精简策略，不是临时开关
常见误以为“断言失效”的真实原因
• Docker 启动命令里写了 python -O app.py，但没意识到 gunicorn 或 uvicorn 默认不透传 -O，需显式配置其 --python-flags 参数
• PyInstaller 打包时用了 --onefile --optimize，隐式启用了 -O，导致打包后所有 assert 消失
• CI/CD 脚本或 Makefile 中 grep 不到 -O，但它可能藏在环境变量 PYTHONOPTIMIZE=1 里
• 本地测试用 IPython（默认不优化），上线却跑在 python -O 的容器里，行为不一致
assert 里有副作用会怎样？
例如写成 assert (x := do_side_effect()), "must be truthy"：
• 正常模式下：执行赋值 + 判断，副作用发生
• -O 模式下：整条语句被删除，do_side_effect() 根本不调用，x 也不会被赋值
• 这不是 bug，是设计保障——你不能依赖 assert 做任何实际工作，它只负责“声明契约”
真正容易被忽略的点是：一旦你把校验逻辑放在 assert 里，就等于主动放弃了生产环境的防护能力。哪怕只有一处 assert isinstance(user_input, dict)，线上收到字符串时也会直通下游，引发更隐蔽的 TypeError 或键访问错误。这不是“要不要加日志”的问题，而是“契约是否在线上成立”的根本判断。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
