何时应使用std::breakpoint而非std::breakpoint_if_debugging？

非调试模式下调用std::breakpoint会永久挂起吗？ #

不会，你的代码在非调试模式下不会永久挂起，而是直接被操作系统终止。

std::breakpoint本质是触发硬件级的断点指令（比如x86架构的int3），当没有调试器捕获这个断点时，操作系统会收到一个未处理的信号（比如Linux下的SIGTRAP，Windows下的EXCEPTION_BREAKPOINT），系统对这类信号的默认处理行为是直接终止进程，而不是让进程挂起等待调试器。所以你的代码执行到std::breakpoint()时会立刻退出，不会执行后面的cout输出。

什么时候该用std::breakpoint而非std::breakpoint_if_debugging？ #

你之前的认知确实有遗漏：断点不只是调试阶段的工具，它在生产环境也有特定的使用场景，需要无条件触发的情况包括：

• 不可恢复的致命错误场景：当程序检测到完全无法恢复的错误（比如核心数据结构被破坏、非法的权限操作、内存 corruption 到不可挽救的程度），继续运行会导致更严重的后果（比如数据丢失、系统资源损坏），此时用std::breakpoint可以强制终止程序，同时如果系统配置了core dump，还能保留错误现场供事后分析——这比让程序“带病”运行要安全得多。
• 生产环境事后调试需求：针对生产环境中偶现、难以复现的问题，开发者可以临时在可疑代码路径插入std::breakpoint，部署到生产环境。当问题触发时，如果有远程调试器附加，能立即现场调试；即使没有，程序终止时生成的core dump也能完整保存错误发生时的内存状态，方便后续离线分析。
• 测试框架的强制断言失败：在自动化测试框架中，有些断言失败属于严重错误，需要立即中断测试流程，不管是在调试环境还是发布版测试环境。用std::breakpoint可以确保测试在失败点立刻停止，避免后续测试步骤被干扰，方便定位问题根源。
• 强制触发调试器附加：在一些特殊场景下，比如需要让程序启动后立刻暂停，等待调试器附加（哪怕是在发布环境），std::breakpoint可以实现这个需求——比如某些需要远程调试的生产服务，启动时触发断点，运维人员可以及时附加调试器进行配置检查。

早期设计的条件断点（类似LLVM和Boost.Test的实现）更偏向于开发阶段的调试辅助，而C++26新增的std::breakpoint则把断点的用途扩展到了生产环境的错误处理和事后调试场景，填补了标准库在这方面的空白。

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