排查过几次程序问题之后，我越来越确信一件事：很多Python开发者对try和except相当熟练，但对raise和assert这两条语句的掌握，往往停留在“见过、偶尔写几行”的程度。异常处理真正的重心，其实不是“怎么接住异常”，而是“在什么时机、以什么形式把异常抛出来”。raise和assert，正是Python里仅有的两条主动制造异常的语句，也是整套异常处理体系的真正起点。
这篇文章会把两者的运行机制、正确用法、常见误用一次讲透。内容不挑版本，代码在Python 3.8及以上都可以直接跑，适合已经会写try/except、但想进一步理解“异常到底从哪里来”的开发者。读完你会发现，真正让代码变得健壮的，往往不是多写几个except，而是把该raise的地方都raise清楚。
1. 为什么说raise和assert才是Python异常体系的真正起点
1.1 从一次“异常被吞掉”的排查说起
有段时间我维护一个数据同步脚本，现象很恶心：任务每过几天就静默失败，日志里只留下一句没有细节的“sync failed after retries”。最初我怀疑是网络抖动，加了各种日志和重试参数，问题依旧。后来一步步追到根因，发现某个子函数在数据格式不合法时直接return None，外层拿到None之后当作“读取成功但数据为空”继续往下处理，数据一路污染了十几层调用，最终以一条笼统的失败信息收场。
如果那个子函数在数据格式不对时不是return None，而是直接raise ValueError("第12行的日期字段格式不对")，traceback会从问题发生的源头一路展示到最外层接收方，整个链路清清楚楚，根本不需要靠猜。这次经历让我意识到，很多人不用raise，不是不会用，而是潜意识里把异常当成“错误”、当成“不友好的东西”。但异常本质上是Python给调用方的一封“信息快递”——它主动告诉你这里出问题了、为什么出问题、在哪出的问题。用好raise，就是在正确的位置发出这封快递。
1.2 traceback里藏着异常设计的核心诉求
试着对比一下子函数失败时的两种信号。
一种：返回None、返回-1、返回空字符串。调用方拿到之后只能靠命名约定去猜，猜错就静默出错。这种风格在C语言时代很流行，因为异常机制成本高。但在Python里，异常本身就是语言特性，你想表达“这事我做不了”，最直接的方式就是raise。
另一种：主动raise。调用方通过except捕获，通过traceback拿到完整上下文，还可以通过异常类型判断问题类别。整个过程信息没有丢失，也没有歧义。
所以在Python里，raise不是破坏流程的坏东西，而是把“失败这件事”变成可处理信息的第一步。理解了这一点，后面的用法就顺理成章了。
2. raise的三层用法：从裸抛到异常链
2.1 入参校验：让错误在源头暴露
写接口和写一次性脚本不一样。脚本出错晚点爆无所谓，但接口是要被很多人调用的，参数错误如果在函数深处才暴露，排查成本会成倍增加。凡是外部传入的参数，都应该在函数入口做校验，不合法就直接raise，不要让脏数据流入核心逻辑。我经常用端口解析来举例：
def parse_port(raw_value: str) -> int: try: port = int(raw_value) except ValueError: raise ValueError(f"端口必须是整数，收到的是 {raw_value!r}") from None if not (1 <= port <= 65535): raise ValueError(f"端口必须在 1-65535 之间，收到的是 {port}") return port这段代码有两个重点。第一，int()本身会抛ValueError，但我把它包成了一个带更清晰信息的ValueError，并额外加上了原始输入值。第二，from None的用意是告诉Python不要再展开底层那层int()转换失败的信息。对调用方来说，“端口必须是整数”已经足够了，再往下展示Python内部转换细节意义不大，反而干扰阅读。
为什么不return -1？因为调用方还得记住-1代表非法，而且-1在某些场景下可能是合法值。用异常直接表达语义，并且不会被忘记处理——只要调用方没接，程序会立刻以清晰的方式停下来，而不是带着错误数据继续运行。这一点在团队协作里尤其重要，因为不是你写的每个调用方都会仔细读函数注释。
2.2 原样重抛：保留现场，不掩盖问题
raise在except块里还有一种特殊写法：后面什么都不跟，只有孤零零一个raise。它的作用是把当前正在处理的异常原样重新抛出去。这种写法适合“我不想处理它，但我要先做一点清理工作”的场景。
import logging logger = logging.getLogger(__name__) def process_line(line: str) -> None: try: value = int(line) except ValueError: logger.warning("跳过无法解析的行: %s", line) raise # 原样重新抛出，交给上层统一处理我见过太多人一进except块就想着“要不要做点什么”，结果要么空except: pass把异常吞了，要么捕获之后只打日志不继续抛、流程继续往下跑，反而制造了更多奇怪的状态。正确的心态应该是：除非你能在这里真正解决这个问题，否则捕获之后就应该让异常继续向上走。
注意，直接写raise和raise e有一个微妙的区别。直接raise会保留原始traceback，包括最初抛出异常的那一行。而raise e会把当前栈信息重新挂上去，在某些情况下看起来像是异常发生在这个except块里，容易误导排查。所以“原样重抛”请务必写裸raise。
2.3 raise...from...：为异常补上“前因”
另一类常见场景是：你在处理某种类型的错误，想把它包装成另一种更贴近业务语义的异常。如果直接raise ConfigLoadError(...)，确实可以，但原始异常信息会通过Python的隐式异常链挂在__context__里，traceback上会显示“During handling of the above exception, another exception occurred”。这种说明不是不好，但显式写from可以让因果关系更明确。
class ConfigLoadError(Exception): pass def load_config(path: str) -> dict: try: with open(path, encoding="utf-8") as f: return json.load(f) except OSError as exc: raise ConfigLoadError(f"无法读取配置文件: {path}") from exc except json.JSONDecodeError as exc: raise ConfigLoadError(f"配置文件不是合法JSON: {path}") from excfrom exc会把原始异常挂到__cause__属性上，traceback里会明确显示“direct cause”。排查问题的时候，你一眼就能看出“配置加载失败”是因为“文件打不开”还是“JSON格式错误”，链路清晰很多。
同样，如果你确定底层异常对调用方没有任何价值，可以用from None把它隐藏。比如把底层的数据库驱动异常包装成业务异常时，你的调用方只关心“这个订单状态不能变更”，没必要看到SQLAlchemy内部的一长串细节。选择from还是from None，核心原则是：调用方需要多少信息，就保留多少信息。
3. assert的真实机制：它为什么会在-O模式下“凭空消失”
3.1 反编译看到的“迷你分支”
assert的语法比raise简单：assert 条件表达式, 可选错误消息。很多教程把它称为“断言”，听起来很高级，但用dis模块拆开看，它本质上就是一个条件判断加抛出语句的组合。
import dis dis.dis("assert x > 0, 'x must be positive'")不同Python版本反汇编结果略有差异，但核心逻辑是一致的：先计算条件表达式，真就跳过去，假就加载错误消息并执行RAISE_VARARGS抛出异常。换句话说，assert x > 0, 'x must be positive'几乎等价于：
if not (x > 0): raise AssertionError('x must be positive')这里有个容易被忽略的冷知识：断言后面的错误消息表达式并不是每次都求值，只有条件为假、进入失败分支时才构造它。所以即使你在消息里写了一个比较耗时的f-string，成功路径上它是完全零开销的，这一点和普通的if分支是一样的。
3.2debug、-O和PYTHONOPTIMIZE的关系
刚才说“几乎等价”而不是“完全等价”，关键就在于内置常量__debug__。CPython在编译一个模块时，如果发现__debug__为False，会直接把整个assert语句从字节码里抹掉，连条件表达式本身都不会求值。
| 运行方式 | debug值 | assert 是否生效 |
|---|---|---|
python script.py | True | 生效 |
python -O script.py | False | 不生效，语句被编译期移除 |
python -OO script.py | False | 不生效，同时移除文档字符串 |
PYTHONOPTIMIZE=1 python script.py | False | 不生效 |
python -O和设置环境变量PYTHONOPTIMIZE=1效果相同，都会把__debug__变成False。-OO在-O基础上还会删除代码对象的__doc__字符串，进一步省内存。
这条机制本身是为生产环境优化准备的：线上运行时不想要的那些检查，可以在编译阶段直接砍掉，换来一点速度提升。但副作用也非常明显——如果断言里面有带副作用的表达式，它在优化模式下根本不会执行。网上常见的一个错误写法是assert (fp := open(path)), "文件打开失败"，这种带海象操作符的断言在python -O下连文件都不会打开。这个教训我记了很久，因为它是真的会让你在生产环境排查半天。
3.3 官方文档为什么劝你别用assert做数据校验
Python官方文档对assert的定位是“插入调试断言的便捷方式”。言下之意，它是写给你自己看的，用来表达“这里按道理走不到”。而用户输入、外部接口传参、命令行参数这些数据，随时都是脏的，你无论如何都不能依赖一个可能被-O关掉的检查来保护线上逻辑。
# 错误：用户输入校验用了assert def register_user(username: str): assert len(username) >= 3, "用户名至少3个字符" ... # 正确：参数校验用raise def register_user(username: str): if len(username) < 3: raise ValueError("用户名至少3个字符") ...更隐蔽的是，有些部署工具、容器镜像、启动脚本会以-O模式运行生产代码。你以为assert能挡住非法数据，实际上一行都没执行。这种问题出现的时候，错误往往已经污染了数据库或者打了几个小时的脏日志，代价非常大。
那assert的正确主场在哪？在测试代码里。Python的单元测试框架和pytest都重度依赖断言，pytest甚至会重写assert的AST，让你在断言失败时看到非常详细的上下文。在测试里用断言验证某个状态是否符合预期，就是它最自然的使用方式。
4. assert和raise的选型边界：仪表盘警告灯与司机喊话
4.1 两种完全不同的语义
我常用一个类比来区分这两个语句：assert是汽车仪表盘上的警告灯，它亮起来说明“某个系统假设被打破了”，比如胎压异常、水温过高，它提示的是车本身出了问题；raise更像是司机向乘客喊话，“站点到了要下车吗”“这个线路走不了”，它交流的是流程中发生的状况。
对应到代码里：assert面向的是“程序内部必然成立的不变量”，它检测的是bug；raise面向的是“外部条件不满足”，它处理的是错误情况。这个区分非常重要，因为这决定了你在哪个层用哪个语句。
比如一个内部业务函数：
def apply_discount(price: float, discount: float) -> float: # 折扣率来自内部业务规则定义，不来自用户直接输入 assert 0 < discount < 1, f"内部折扣率必须位于(0,1)，实际是 {discount}" return price * (1 - discount)如果discount是配置文件里读出来的，我会把它改成raise ValueError，因为配置文件是外部输入；如果它只是内部一个常量，那么assert作为防御性编程是合适的，它能在开发阶段快速暴露出“有人改了规则但没同步”的问题。
4.2 从调用方视角看两种抛错契约
用一个表格把这组对比整理清楚，平时做技术方案时可以直接参考：
| 维度 | assert | raise |
|---|---|---|
| 面向对象 | 程序内部假设、不变量 | 调用方、外部条件、业务规则 |
| 默认抛出的类型 | AssertionError | 抛出指定异常类型 |
| 优化模式下 | 整个语句被移除 | 永远生效 |
| 消息消费者 | 开发者自己 | 调用方/用户 |
| 典型场景 | 算法前后置条件、数据结构一致性、分支到达不了的地方 | 参数校验、资源失败、业务规则冲突 |
| 设计初衷 | 调试辅助 | 错误传递 |
这套对照表很多时候可以直接当团队规约来用。“代码评审的时候看到assert用于外部输入，直接驳回”，这一条就能挡住很多潜在线上事故。
4.3 EAFP风格里raise的正确定位
Python社区一直提倡EAFP（easier to ask for forgiveness than permission），也就是“先尝试做，失败了再处理”，而不是LBYL（look before you leap，做之前先把所有可能的坑检查一遍）。在这种风格里，raise承担的任务非常重——它允许函数直接尝试执行，一旦失败就把具体原因作为异常抛出去，让上层决定怎么兜底。
比如读取用户输入的数字：
# LBYL 风格 def read_int(): value = input("输入数字: ") if not value.isdigit(): return None return int(value) # EAFP 风格 def read_int(): value = input("输入数字: ") return int(value) # 不是数字时，int()会抛ValueError前一种把“会失败的可能性”变成了一堆if判断，后一种直接把失败交给异常体系。而让失败真正浮出水面的，正是底层的raise——内置函数int()内部遇到非法输入就会raise ValueError，这本身就是raise应用的典范。所以写Python，越早接受“失败就用异常表达”，代码风格就越地道。
5. 祖传代码里的三类异常滥用，以及正确的重构姿势
5.1 裸except吞异常：错误被藏得越深，排障时间越长
老代码里最令人头疼的写法是这种：
try: result = api.call() except Exception: pass这个写法把异常全部接住，然后什么都不做。开发的时候你可能觉得“反正我也不想让它崩”，但在生产环境这等于把故障灯插头拔了。系统挂了但进程还在，数据错了但没人知道，等到你发现的时候，要么日志早就刷没，要么已影响了一大批数据。
重构的方式很简单：至少记一条日志，再用raise把异常往上抛。
import logging logger = logging.getLogger(__name__) try: result = api.call() except Exception: logger.exception("调用API失败") raiselogger.exception会带着当前异常的完整traceback记录到日志里，然后raise继续向上传递。如果上层也没有能力处理，那就让程序以明确的方式停在这一步，而不是带着半截结果继续运行。如果你在维护老代码，看到这种裸except，第一步先判断它是不是把异常信息丢掉了，第二步再决定补日志还是直接交给上层。
5.2 用assert验证外部输入：一开优化模式就全线失守
这个坑在第3章已经讲清楚了，但在真实代码里出现频率实在太高，值得单独列一条。用户输入、命令行参数、外部配置文件、网络请求返回值，这些全部属于外部输入，必须用raise做校验。
def create_user(username: str, email: str): # 错误：如果部署时带-O，这段校验完全不生效 assert len(username) >= 3, "用户名太短" assert "@" in email, "邮箱格式错误"很多新手这样写，是因为它短、省事、还能把错误消息写得很友好。但“省事”绝不能建立在“线上保护可能被关闭”的基础上。正确写法是把每个检查都拆成显式的if+raise，或者写一个集中的校验函数来减少重复代码。
5.3 所有错误都抛同一个Exception：调用方无法分类处理
还有一种滥用正好相反——没有分类意识，一律抛最顶层的Exception：
if not config_file.exists(): raise Exception("配置文件不存在") if not valid_format(config_file): raise Exception("配置格式错误") if port == 0: raise Exception("端口不能为0")三个完全不同的错误，抛的是同一个异常类型。调用方不得不通过字符串匹配去猜发生了什么，只要提示文字改动一行，行为就变了。正确做法是定义几个有语义的异常类型，或者至少把它们划分到内置异常的不同类别里。
如果不想马上引入自定义异常体系，也有一个低成本的过渡方案：参数错误统一用ValueError，类型错误用TypeError，运行时环境问题用RuntimeError，资源找不到用FileNotFoundError。这个切换成本很低，但已经能帮助调用方做分类处理了。
6. 构建可维护的异常体系：自定义异常与层次化处理
6.1 为什么要自定义异常：用类型传递信息，而不是靠猜
当项目大到一定程度，内置异常就不够用了。ValueError既能表示端口不对，也能表示用户名重复，调用方没法区分到底发生了什么。自定义异常的价值在于让异常类型本身成为一份契约——看到类型，就知道是哪一类问题。这个信息密度是纯字符串无法提供的。
一个精简的做法是定义应用统一的异常基类，然后按业务域拆分细类：
class AppError(Exception): """应用统一错误基类""" class ConfigError(AppError): """配置相关错误""" class ConfigLoadError(ConfigError): """配置加载失败""" class PortValidationError(ConfigError): """端口参数校验失败"""外层代码只需要except AppError就能接住所有业务异常，而具体处理时又可以根据子类型区分策略。
6.2 一个标准校验器案例：入口参数、配置解析、运行时错误分家
把前面几个示例串起来，就是一个完整的命令行工具骨架：
import json import logging logger = logging.getLogger(__name__) class AppError(Exception): pass class ConfigError(AppError): pass class ConfigLoadError(ConfigError): pass class PortValidationError(ConfigError): pass def parse_port(raw_value: str) -> int: try: port = int(raw_value) except ValueError: raise PortValidationError(f"端口必须是整数: {raw_value!r}") from None if not (1 <= port <= 65535): raise PortValidationError(f"端口超出范围: {port}") return port def load_config(path: str) -> dict: try: with open(path, encoding="utf-8") as f: return json.load(f) except OSError as exc: raise ConfigLoadError(f"配置文件无法读取: {path}") from exc except json.JSONDecodeError as exc: raise ConfigLoadError(f"配置文件不是合法JSON: {path}") from exc def main(): try: raw_port = get_command_line_arg("--port") port = parse_port(raw_port) config = load_config("app.json") # 业务逻辑... except ConfigError as exc: print(f"配置错误: {exc}") raise SystemExit(1) from exc except AppError as exc: logger.exception("应用运行失败") raise最外层只捕获基类ConfigError，内部具体子类自然会被接住。用户看到的是友好提示，开发者看到的是完整traceback。特意用SystemExit(1) from exc而不是普通异常，是因为SystemExit属于BaseException，不会被外层except Exception误伤，同时from exc又保留了退出原因，排查时不会丢失上下文。
6.3 异常上下文：让异常携带足够多的诊断信息
自定义异常除了消息，还可以挂属性。这样在except块里能拿到结构化信息，而不只是拼好的字符串。这在处理外部数据时尤其好用：
class PortValidationError(ConfigError): def __init__(self, message: str, raw_value=None): super().__init__(message) self.raw_value = raw_value raise PortValidationError( f"端口必须是整数: {raw_value!r}", raw_value=raw_value, )排查问题的时候，直接把exc.raw_value打到日志里，就能快速复现原始输入是什么，而不是靠猜测去构造触发条件。这个习惯一旦养成，你会发现线上排障的很多“玄学”时间都被压缩了。
我个人的建议是，从今天开始，在你写的每个需要外部输入的函数入口处，先把“不合法就raise”这个动作补上。然后检查一下现有的assert，凡是用于校验外部数据的，都改成raise。这两步做完，你的代码在排障阶段的体验会立刻不一样——至少你不会再遇到那种“日志一片平静、但结果完全不对”的诡异问题。
