在Python自研Django共享库中使用assert做变量校验的可行性及方法

可以用，但要明确assert的适用边界和正确用法，以下是具体分析：

一、适用场景（推荐用assert的情况） #

• 内部调用的前置条件校验：你的自研库仅在团队内部的Django项目或组件间共享，调用方都是可控的内部代码，此时assert可以作为开发阶段的"快速自检工具"，提前发现调用时的参数错误，避免错误逻辑扩散。
• 拦截逻辑上的不可能分支：像你示例中，业务逻辑明确logic只能是and或or，用assert拦截else分支的非法值，比静默假设值为另一种更合理——能立刻暴露代码中的逻辑漏洞，而不是让错误悄悄延续。

二、不适用场景（禁止用assert的情况） #

• 校验外部用户输入：如果logic这类参数来自前端提交、API外部调用等不可控来源，绝对不能用assert。因为Python启动时加-O优化参数会直接移除所有assert语句，导致校验完全失效，此时必须用常规条件判断+抛出ValueError/Django ValidationError这类业务异常。

三、你的示例写法分析 #

两种写法都可行，但更推荐第一种带错误信息的写法：

if logic == 'and':
    main_Q = main_Q & filter_Q
elif logic == 'or':
    main_Q = main_Q | filter_Q
else:
    assert False, "Invalid value of `logic`, it needs to be either `and` or `or`."

这种写法在断言失败时能直接给出清晰的错误原因，调试时不用额外翻代码上下文；第二种写法assert logic == 'or'虽然简洁，但错误信息模糊，排查问题效率更低。

四、开源库中的assert用法参考 #

你在amqp、celery等库中看到的assert，本质都是用来校验内部逻辑的不变量或可控调用的前置条件：比如assert isinstance(mechanism, bytes)是确保库内部调用时传入的参数类型符合预期，这些场景都是库开发者能控制的调用路径，或者是要求使用者遵守的约定，用assert可以快速发现使用错误，降低调试成本。

五、Django环境下的运行影响 #

你测试发现断言失败仅终止单个请求线程、不会导致项目崩溃，这是符合Django运行机制的：WSGI/ASGI服务器会为每个请求分配独立线程/协程，单个线程的断言异常会被服务器捕获并返回500错误，不会影响其他请求。但要注意两个点：

1. 如果生产环境开启了-O优化（部分部署脚本会默认添加），所有assert会被直接移除，此时这些校验会完全失效。如果是生产环境必须保留的校验，建议替换为抛出明确异常：

   else:
       raise ValueError("Invalid value of `logic`, it needs to be either `and` or `or`.")
   

2. 即使生产环境不开启优化，断言失败返回的500错误对用户不友好，所以如果参数可能来自不可控路径，还是用常规异常更合适。

内容的提问来源于stack exchange，提问作者James