一、断言的本质：什么是断言？断言与异常处理的区别
大家好，我是你们的调试课讲师。今天咱们来聊聊断言——这个看似简单、实则门道不少的话题。
先问大家一个问题：你写代码的时候，有没有过这样的经历——程序跑着跑着突然崩了，你翻遍日志也找不到原因？我遇到过太多次了。后来我发现，很多崩溃其实是可以提前预判的。而断言，就是帮你做这件事的。
1.1 断言到底是什么？
说白了，断言就是代码里的一个“安全检查点”。它检查某个条件是否为真。如果为真，程序继续跑；如果为假，程序立刻停下来，并告诉你“这里出问题了”。
我个人习惯把断言想象成代码里的“哨兵”。它站在关键路口，帮你盯着那些“不应该发生”的事情。
核心定义：断言是一种用于在开发阶段检测程序内部错误的机制。它假设某个条件永远为真，如果条件不成立，则立即终止程序并报告错误。
举个例子，你写了一个函数，要求传入的参数必须是正整数。你心里清楚：如果传了负数或零，后面的逻辑全都会乱套。这时候，你就可以放一个断言在函数开头。
def calculate_discount(price, rate):
# 断言：价格必须大于0，折扣率必须在0到1之间
assert price > 0, "价格必须为正数"
assert 0 <= rate <= 1, "折扣率必须在0到1之间"
return price * (1 - rate)你看，这两行断言就像两个门卫。它们不负责处理业务逻辑，只负责说“不”。一旦发现不对劲，立刻拉响警报。
1.2 断言 vs 异常处理：它们到底有啥区别？
很多初学者会问：断言和 try-except 不都是处理错误的吗？有什么区别？
嗯，这个问题问得好。我刚开始学 Python 时也困惑过。后来在项目里摔了几次跟头，才真正搞明白。
咱们用一个表格来对比一下：
| 对比维度 | 断言 (assert) | 异常处理 (try-except) |
|---|---|---|
| 设计目的 | 检测程序内部逻辑错误 | 处理可预见的运行时异常 |
| 使用场景 | 开发阶段、测试阶段 | 生产环境、用户交互 |
| 能否被捕获 | 可以，但通常不应该捕获 | 应该被捕获并处理 |
| 默认行为 | 触发 AssertionError，程序终止 | 执行 except 块中的代码 |
| 性能影响 | 可被全局禁用（-O 选项） | 始终生效 |
| 信息详细度 | 通常只输出简单消息 | 可包含完整的堆栈和上下文 |
看到这个表格，你可能已经有点感觉了。我再给你讲个我亲身经历的事。
我曾经维护过一个支付系统。有一次，用户反馈说“扣了钱但订单没生成”。我查了半天日志，发现是某个中间件返回了一个空值。按理说，这个中间件不应该返回空值——这是系统内部的约定。但代码里没有检查，结果空值一路传下去，最后订单创建失败。
你想想看，如果当时在接收中间件返回值的地方加一句断言：
response = payment_gateway.process(order)
assert response is not None, "支付网关返回了空响应，请检查网关状态"那在开发测试阶段就能发现问题，根本不会留到线上。这就是断言的价值——它帮你抓住那些“不应该发生”的错误。
1.3 什么时候用断言，什么时候用异常？
我总结了一个简单的判断原则：
- 用断言的情况：这个错误如果发生了，说明你的代码有 bug。比如函数参数类型不对、某个内部状态不应该为 None、某个列表不应该为空。
- 用异常的情况：这个错误即使发生了，程序也应该能优雅地处理。比如用户输入了非法数据、网络请求超时、文件不存在。
说白了，断言是给开发者看的，异常是给用户看的。
我的建议：在开发阶段，多用断言来验证你的假设。等代码稳定了、要上线了，再把关键的断言替换成更友好的异常处理。但别全删掉——那些检查内部逻辑的断言，留着也没坏处。
1.4 断言的一个常见误区
我曾经见过一个同事，在代码里这样写：
assert user.delete(), "删除用户失败"你看出问题了吗？user.delete() 是一个有副作用的操作——它真的会去删除数据库里的记录。如果断言被禁用了（比如用 python -O 运行），这行代码根本不会执行！
警告：永远不要在断言中执行有副作用的操作！断言可能会被全局禁用。正确的做法是：先执行操作，再用断言检查结果。
正确的写法应该是：
result = user.delete()
assert result, "删除用户失败"这样，即使断言被禁用，user.delete() 也会正常执行。
1.5 本章知识体系
为了帮你更直观地理解断言在整个调试体系中的位置，我画了一张图：
从这张图你可以看到，断言不是孤立存在的。它和日志记录、异常处理一起，构成了我们调试的三大武器。三者各有分工，互相配合。
1.6 小结
好了，咱们来捋一捋今天的内容：
- 断言是代码里的“安全检查点”，用来验证那些“不应该发生”的事情
- 断言和异常处理有本质区别：断言针对内部逻辑错误，异常处理针对可预见的运行时问题
- 不要在断言里写有副作用的代码
- 开发阶段多用断言，生产环境用异常处理
记住一句话：断言是你代码的“良心”。它在你犯错的时候，第一时间告诉你“嘿，这里不对劲”。学会用好它，你的代码质量会上一个台阶。
下一章，咱们聊聊断言的具体语法和最佳实践。到时候我会分享一些我在实际项目中踩过的坑，保证让你少走弯路。
可可精品资料库