assert 是契约声明而非调试工具，仅用于开发阶段保证成立的内部逻辑，如函数前置条件、类不变量等；生产环境禁用后失效，不可替代输入校验或异常处理。
assert 语句不是调试开关，而是契约声明
assert 不是用来“临时检查变量值”的调试工具，它是你对代码运行时状态的明确承诺：这里必须为真，否则说明逻辑已失控。一旦触发，AssertionError 表明程序进入了你不预期、也不愿继续执行的状态——它不该被 try/except 捕获后吞掉，而应暴露问题。
常见错误是把 assert 当成日志或容错处理：
- 在生产环境关闭
-O优化时仍依赖assert做输入校验（它会被完全移除） - 写
assert x is not None, "x missing"却没配文档说明这是调用方责任 - 在循环内部频繁断言同一条件，拖慢性能且掩盖真正问题点
只在不变量和前置条件上用 assert
适合断言的场景非常有限：函数入口的参数约束、关键计算前的中间状态、类不变量（如 self._size == len(self._data)）、算法关键分支的假设。它不替代类型检查或业务规则校验。
例如：
立即学习“Python免费学习笔记（深入）”；
def binary_search(arr, target):
assert isinstance(arr, list), "arr must be a list"
assert all(isinstance(x, (int, float)) for x in arr), "arr elements must be numbers"
assert arr == sorted(arr), "arr must be sorted" # 这里是算法前提，不是用户输入校验
# … 实际搜索逻辑
注意：assert 中的表达式在 -O 下被跳过，所以不能放有副作用的代码（比如 assert log_debug(), "debug failed"）。
assert 和 if raise 的分工要清楚
用户输入、外部数据、I/O 结果等不可控因素，必须用 if + raise ValueError 等显式异常；assert 只用于开发阶段能保证成立、上线后理应永不失败的内部逻辑。
- 该报错给调用方看？→ 用
raise TypeError - 该报错提醒自己逻辑错了？→ 用
assert False, "unreachable" - 该检查配置是否加载成功？→ 用
if not CONFIG: raise RuntimeError，不是assert CONFIG
一个典型混淆点：assert os.path.exists(path) 看似合理，但文件可能被并发删除，这不是代码 bug，而是运行时环境变化，应该用 os.stat() 捕异常处理。
Pytest 中 assert 是核心，但行为不同
在测试里，assert 是第一公民，pytest 会重写其字节码，提供详细的差值对比（比如列表元素差异、字符串行 diff）。但它依然遵循“契约”本质：测试失败意味着被测代码没满足你写的断言条件。
别写这种测试：
def test_parse_config():
data = parse_config("config.yml")
assert data # 太模糊，失败时看不出哪条字段缺失
assert "host" in data # 更好，但不如直接 assert data["host"] == "localhost"
真正有用的断言要具体到字段和预期值，否则等于没断言。另外，pytest 不推荐用 assertRaises，直接写 with pytest.raises(ValueError): func() 更清晰。
assert 的力量不在多，而在准——它只该出现在你敢拍胸脯说“这里绝不可能出错”的地方。一旦它被触发，说明你的设计假设崩了，得回溯根源，而不是加个 try 掩盖。
