assertionerror 是开发期逻辑自检信号，非业务校验工具；它继承自 error，应冒泡终止流程而非捕获恢复；仅适用于内部不变量校验，生产环境会被彻底移除。
AssertionError 不是业务校验工具，而是开发期逻辑自检信号。它被设计为“可被安全移除”的调试辅助，而非运行时必须生效的控制分支。一旦在生产环境误用，轻则校验失效，重则掩盖真实错误、引发连锁崩溃。
断言在生产中会被彻底擦除
Java 默认禁用断言，需显式加 -ea 才生效；Python 在 -O 或 -OO 模式下，assert 语句连同其条件表达式都会从字节码中删除——不是“不执行”，而是“不存在”。这意味着：
- CI/CD 脚本或 Docker 启动命令里一个
python -O app.py，所有断言瞬间归零 -
-OO还会删掉文档字符串，可能破坏依赖__doc__的测试发现机制 - 你本地能拦住非法输入，上线后却直接传入负数参与计算，后续报
ArithmeticException或静默结果错误
AssertionError 继承自 Error，不是 Exception
它属于 JVM / 解释器认定的“不可恢复严重问题”，与 OutOfMemoryError 同级。规范做法是让它冒泡终止当前流程，而不是 try-catch 吞掉再继续执行：
- 捕获
AssertionError并试图恢复业务流，违背其语义初衷 - IDE 或日志系统可能默认忽略或特殊标记
Error类型，导致问题难以追踪 - 多数监控平台对
Error的告警阈值、采样策略与Exception不同，容易漏报
业务逻辑校验必须无条件生效
用户输入合法性、权限状态、资源可用性、参数范围等，都要求在任何运行配置下强制检查。正确方式是显式抛出语义明确的异常：
- 用
if (id == null) throw new IllegalArgumentException("id must not be null") - 用
Objects.requireNonNull(obj, "obj is required") - 用 Pydantic 模型、Spring Validation 注解等框架级校验层，而非手写 assert
断言的合理使用边界很窄
它只应在满足以下全部条件时出现：
- 校验的是程序内部不变量（如“这个私有方法返回前，缓存 size 必须等于 keySet.size()”）
- 该条件理论上绝不可能为假，一旦为假说明代码存在根本性缺陷
- 你接受它在优化构建中消失，且不依赖它保障系统稳定性
- 仅用于开发/测试阶段快速暴露低级错误，不作为线上防御手段
