assert在生产环境被-O参数编译期剔除，不执行、不检查、不报错；应改用if+raise做运行时校验，优先内置异常，高频路径避免耗时操作，用类型检查工具替代逻辑断言，以日志监控替代崩溃。
assert在生产环境会被完全忽略
Python解释器启动时加 -O（optimize）参数，所有 assert 语句会被直接移除，不执行、不检查、不报错。这不是“禁用”，而是编译期剔除——哪怕断言里有副作用（比如调用函数），也会一并消失。
常见误操作：python -O script.py 看似生效，但若项目通过 gunicorn、uvicorn 或其他方式启动，需确认其是否透传 -O；Docker镜像若用 python:slim 默认不带 -O，必须显式配置启动命令。
-
assert不是错误处理机制，它只用于开发/测试阶段的快速自检 - 线上日志里突然看不到
AssertionError，未必是代码修复了，很可能是被-O静默吞掉了 - 依赖
assert做输入校验（如assert isinstance(x, int)）在线上等于无效防护
用if + raise替代assert做运行时校验
把 assert 改成显式条件判断，才能确保逻辑在线上稳定触发。关键不是“换写法”，而是明确区分：什么该报错中断，什么该记录告警继续执行。
例如验证API参数类型：
立即学习“Python免费学习笔记（深入）”；
# ❌ 危险：assert在-O下失效
assert isinstance(user_id, int), "user_id must be int"
<h1>✅ 安全：显式校验+可定制异常</h1><p>if not isinstance(user_id, int):
raise ValueError("user_id must be int")
- 优先用内置异常（
ValueError、TypeError、KeyError），别总用Exception - 如果需要区分场景，可定义业务异常类，但避免过度抽象
- 对高频路径（如请求入口），校验逻辑要轻量，避免在
if里做耗时操作（如DB查询）
哪些assert不该删，而该保留为文档注释
有些 assert 实际是“不可能到达”的逻辑断言，比如 if...elif...else 覆盖全部枚举值后，在 else 里写 assert False。这类断言在线上虽消失，但能帮开发者理解控制流约束。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
更稳妥的做法是用类型提示 + 类型检查工具（如 mypy）替代：
from typing import Literal <p>def handle_status(status: Literal["pending", "done", "failed"]) -> str: if status == "pending": return "waiting" elif status == "done": return "success" elif status == "failed": return "error"</p><h1>mypy 能静态推导此处 status 已穷尽，无需 assert False</h1><p>
- 用
Literal、Enum或TypedDict让类型系统捕获漏分支，比运行时assert更早发现问题 - CI中加入
mypy检查，比依赖线上抛AssertionError可靠得多 - 别在循环内部或热点路径写
assert，即使不加-O，它也有运行时开销
日志 + 监控比断言更能暴露线上问题
断言失败意味着程序已进入不可预期状态，但生产环境真正需要的是：这个状态是否频繁发生？影响范围多大？能否自动恢复？
与其让服务因 AssertionError 崩溃，不如记录结构化日志并触发告警：
import logging
<p>logger = logging.getLogger(<strong>name</strong>)</p><p>if not is_valid_config(config):
logger.error("Invalid config detected", extra={"config": config})</p><h1>这里可触发降级逻辑，而非直接 raise</h1><pre class="brush:php;toolbar:false;">use_default_config()
- 用
logging.error记录异常上下文，比assert的字符串消息信息量大得多 - 配合
loguru或structlog输出 JSON 日志，方便 ELK / Grafana 关联分析 - 对关键断言点（如库存扣减前的余量检查），额外上报监控指标（如
inventory_assert_failures_total）
断言的本质是“我假设这个为真”，而生产环境必须面对“它可能为假”。把假设变成可观察、可量化、可响应的动作，才是落地的关键。
