Chromium及V8源码中DCHECK与CHECK的使用选择疑问

核心区别 #

• CHECK：发布版和调试版均生效，触发后直接终止程序，用于拦截不可恢复的、违背核心逻辑的错误，这类错误出现意味着程序已处于严重异常状态，必须立即停止以避免更严重的问题。
• DCHECK：仅调试版生效，发布版会被编译移除，用于验证开发阶段的逻辑假设——这些假设理论上在正常流程中不会被打破，仅在调试时快速暴露潜在问题。

选用的核心原则 #

优先使用CHECK的场景 #

• 检查外部不可控输入：比如用户输入、跨进程传递的数据、网络请求参数等，这类输入无法保证合法性，必须在发布版保留检查，防止恶意输入引发崩溃或安全风险。
• 验证依赖系统的关键结果：比如操作系统API调用失败、内存分配失败（CHECK(ptr != nullptr)），这类错误属于不可恢复的严重问题，终止程序是最优选择。
• 确保核心业务逻辑的一致性：比如状态机跳转违反设计规则、核心数据结构被破坏，这类错误意味着程序逻辑存在根本性缺陷，发布版必须拦截。

优先使用DCHECK的场景 #

• 检查内部函数的参数合法性：如果函数仅在模块内部调用，且调用方理应保证参数合法（比如私有函数、内部工具函数），用DCHECK在调试阶段验证调用方是否遵守约定，发布版移除检查以提升性能。
• 验证数组/容器的边界：如果索引由内部逻辑计算得出（比如循环变量、已通过前置验证的索引），理论上不会越界，用DCHECK在调试时快速发现逻辑漏洞，发布版无需额外检查以避免性能开销。
• 标记临时开发假设：比如某个分支逻辑暂时认为不会被触发，用DCHECK标记，后续逻辑变更触发该分支时，调试阶段会立即告警。

为什么会出现“本该用CHECK却用了DCHECK”的情况？ #

• 性能优先策略：Chromium/V8对性能极其敏感，部分边界检查虽看似重要，但经评审确认仅在内部逻辑触发，且调用方已通过其他前置检查保证合法性，此时为了发布版性能会选择DCHECK。
• 逻辑上下文的确定性：比如数组索引来自已通过CHECK验证的容器，后续使用该索引时，DCHECK足以覆盖调试阶段问题，发布版无需重复检查。
• 代码迭代优化：代码演进中，原本的外部输入可能变为内部参数，或新增了前置验证逻辑，导致原本的CHECK被改为DCHECK以优化性能。

实践建议 #

• 编写新代码时，先判断检查对象：若为外部不可控输入优先用CHECK；若为内部逻辑自我验证用DCHECK。
• 遇到现有代码中DCHECK用于边界/类型检查时，先查看上下文是否有前置CHECK验证，或该参数是否仅在内部传递。
• 调试阶段触发DCHECK必须修复，这意味着你的逻辑违背了代码的预设前提，即使发布版不崩溃，也可能引发隐藏的内存问题或逻辑错误。

内容的提问来源于stack exchange，提问作者王艳明