断言崩溃是运行时 sigabrt，源于 abort() 调用，不可被 try/catch 捕获；修复须回溯非法输入源头，保留 assert 前提是条件可静态验证且有明确修复路径，线上应禁用但代之以显式校验。
类型断言崩溃不是“语法错误”，而是运行时触发的 SIGABRT，根本原因在于断言失败后调用 abort() —— 修复必须从“为什么断言会失败”入手，而非屏蔽信号或忽略报错。
为什么 assert() 崩溃后无法简单 catch？
在 C/C++ 中，assert() 不是异常，它底层直接调用 abort()，发送 SIGABRT 信号。这个信号默认不可被 try/catch 捕获（C++ 异常机制不接管），也无法用 signal(SIGABRT, handler) 安全恢复执行流——强行处理只会掩盖问题、导致状态不一致。
- 断言失败 = 程序已处于非法状态，继续运行风险远大于终止
- gdb 中看到
Program received signal SIGABRT, Aborted.，说明崩溃点就是断言触发处，不是下游副作用 - Release 模式下
assert()被编译器移除，所以崩溃只出现在 Debug 构建，容易误判为“测试环境特有”
定位真实断言失败点的三步法
不要只看崩溃栈顶；assert() 是守门人，它拦下的一定是上游逻辑漏洞。关键动作是回溯“谁传了非法参数进来”。
- 用
gdb ./app core启动后，先执行bt查看完整调用栈，重点关注断言所在函数的调用者（即上一级 frame） - 对每个可疑 frame 执行
frame N+info args，检查传入参数值（如data是否真为nullptr、size是否为 0） - 若参数本身合法，再查该参数的来源：是配置读取？网络解析？还是前序计算结果溢出？例如
size来自strlen(buf)，但buf未初始化 → 根因在 buf 初始化，不在 assert
assert() 该保留还是删掉？
保留，但必须满足两个前提：断言条件可静态验证、且失败路径有明确修复手段。否则就是“伪防御”。
- ✅ 合理用法：
assert(ptr != nullptr)（指针所有权明确由当前模块保证） - ❌ 危险用法：
assert(fd >= 0)（文件描述符来自系统调用，应检查返回值并处理错误，而非断言） - ⚠️ 替代方案：对不可控输入（如用户数据、网络包），用
if (!valid) { log_error(); return; }，而不是assert(valid) - ? 提示：把
assert()当作开发期契约文档——它写在哪里，就说明“此处代码作者承诺输入满足该条件”，违反即需重构契约，而非删断言
线上环境如何避免断言崩溃影响服务？
核心原则：断言只用于开发/测试阶段暴露逻辑缺陷，绝不应成为线上稳定性瓶颈。但不能靠关断言来“修复”。
- 构建时区分环境：
-DNDEBUG仅用于 Release 构建，确保线上二进制不含assert()，但同步启用更严格的运行时校验（如参数合法性 check + 错误码返回） - 崩溃后必须复现：拿到 core 文件后，用带符号表的 Debug 版本
gdb加载，确认断言条件为何被违反——这是唯一能根治的办法 - 警惕“修复后仍崩溃”：比如修复了 A 函数的空指针断言，但 B 函数同样位置又崩了，说明共用逻辑（如某结构体初始化函数）漏处理
真正难的不是让程序不崩，而是让每次崩溃都精准指向一个可归因、可验证、可单元测试的逻辑缺陷。断言崩溃恰恰是这种精确性的体现——别绕开它，得顺着它找到那个没被写进测试用例的边界条件。
