assert是关键字语句，正确写法为assert condition, message；condition须为纯布尔表达式，不可加括号，否则可能因误构元组导致断言失效；仅用于开发期自检，-O模式下被忽略。
assert 语句写法：不是函数，别加括号调用
很多人一看到 assert 就下意识写成 assert(...)，像调用函数一样——这是错的。assert 是 Python 的关键字语句，语法是 assert condition, message，不是函数调用。写成 assert(1 == 2) 看似能跑，但其实是在构造一个带括号的布尔表达式，一旦 condition 是元组（比如误写成 assert(a, b)），它永远为真，断言完全失效。
常见错误现象：assert(x > 0, "x must be positive") —— 这里 (x > 0, "x must be positive") 是个非空元组，恒为 True，断言从不触发。
- 正确写法：
assert x > 0, "x must be positive" - 条件部分必须是纯布尔表达式，不要套括号
- 提示消息可选，但建议写，尤其在多人协作或复杂校验时
- 注意：
assert在运行时加-O（优化模式）会被完全忽略，不能用于关键业务逻辑校验
什么时候该用 assert，什么时候不该用
assert 只适合做「开发期快速自检」，比如验证函数输入是否符合内部假设、检查中间状态是否合理。它不是异常处理机制，也不该替换成 if ... raise。
使用场景举例：
立即学习“Python免费学习笔记（深入）”；
- 调试时确认某个变量“按理说不可能为 None”：
assert data is not None, "data unexpectedly None after load" - 单元测试前快速过滤明显异常输入：
assert len(items) > 0（但正式逻辑里仍需处理空列表） - 算法内部不变量检查，如二分查找中
assert left
不该用的场景：
- 用户输入校验（应抛出
ValueError或自定义异常） - 文件/网络等外部依赖失败（应捕获
IOError或重试） - 任何需要在生产环境生效的检查（
-O下直接消失）
assert 和 if raise 的性能与语义差异
表面上看，assert condition, msg 和 if not condition: raise AssertionError(msg) 效果相似，但语义和行为完全不同。
关键区别：
-
assert是开发辅助工具，语义是“这里如果假，说明代码有 bug，我要立刻停下来”；if raise是运行时控制流，语义是“这个条件不满足是可能发生的，我按规则处理” - 性能上，
-O模式下assert被编译器移除，零开销；if raise始终存在，哪怕条件恒真也要判断一次 - 堆栈信息不同：
assert报错显示AssertionError，位置精确到断言语句行；手动raise则多一层调用帧，有时掩盖真实问题点 - 静态分析工具（如 mypy、pylint）对
assert有特殊理解，能据此推断类型（例如assert isinstance(x, str)后，后续代码中 x 被视为str类型）
容易被忽略的兼容性陷阱
Python 3.11+ 引入了 ExceptionGroup 和更细粒度的异常链，但 assert 依然只抛 AssertionError，且不支持嵌套异常。这点在集成测试框架或错误聚合系统中容易出问题。
另一个隐蔽坑：某些 IDE 或调试器（如 PyCharm 的断点条件）会把 assert 当作普通语句跳过，导致你以为它执行了，其实根本没走那条分支。
- CI/CD 流水线若用
python -O运行测试，所有assert都失效，可能漏掉本该暴露的问题 - 在
__slots__类或 frozen dataclass 中，assert放在__init__末尾检查字段值没问题，但别指望它能替代@property或__post_init__的完整校验逻辑 - 异步函数里用
assert没问题，但它不能 await，也不能检查协程对象是否完成——要检查的是await coro的结果，不是coro本身
最常被忽略的一点：assert 不是文档，也不是契约。它不生成 API 文档，不参与类型注解，也不被 mypy 默认检查（除非开启 --warn-unused-ignores 或配合 typing.cast）。靠它“保证正确性”，等于把测试责任偷偷塞给运行时。
