一、前言
在大型 C++ 工程（例如 Chrome 浏览器内核）中，开发者经常会遇到这样的选择：
到底应该在关键点使用 CHECK 直接崩溃，还是使用 return、LOG 记录错误然后继续执行？
这看似只是一个代码风格问题，实则背后牵扯到 线上崩溃率、稳定性、用户体验、以及问题定位效率。
本文结合浏览器内核的真实代码案例，从源码设计出发，分析 CHECK 与 return 的差异，探讨它们在 稳定性优化 和 线上质量保障 中的取舍，并给出一些落地的优化实践经验。
二、背景知识：什么是 CHECK
在 Chromium 基础库（base/check.h）中，CHECK 是一个类似于断言的宏，用法非常常见：
CHECK(pointer); CHECK_EQ(size, expected_size); 和 DCHECK 不同的是：
-
CHECK永远生效 （无论 Debug 还是 Release），失败时会直接触发 致命崩溃 （调用ImmediateCrash()）。 -
DCHECK只在 Debug 或启用了--enable-dcheck的模式下才有效，Release 默认不生效。
也就是说：
-
CHECK = 防御型编程 + 线上崩溃
-
DCHECK = 调试模式下的保护网
因此，使用 CHECK 的地方，意味着开发者明确认为 "如果条件不满足，继续运行程序只会带来更大风险，还不如直接崩溃并上报"。
三、典型代码案例分析
以浏览器 UI 初始化的一个场景为例：
ViewBuilder buildui; const ui::ThemeProvider* tp = GetThemeProvider(); if (tp) { base::RefCountedMemory* memory = tp->GetRawData("browser.xml", ui::k100Percent); CHECK(memory); if (memory) { buildui.BuilderUiUtf8((const char*)(memory->front()), this); } } 3.1 为什么这里要用 CHECK？
-
browser.xml是浏览器 UI 布局的核心资源，缺失后界面几乎无法正常渲染。 -
如果
memory == nullptr，继续运行只会导致后续逻辑 不可控 ，甚至触发 更隐蔽的崩溃。 -
与其后面某处 随机崩溃，不如在这里立刻崩溃并生成明确的堆栈。
这就是 "快速失败（fail fast）" 的思想。
3.2 如果换成 return，会发生什么？
假设我们改成：
if (!memory) { LOG(ERROR) << "browser.xml not found!"; return; } 那么结果可能是：
-
浏览器启动后黑屏、空白 UI，但进程没崩溃。
-
用户上报 "浏览器打不开界面"，但 crash dump 无法收集到。
-
问题变成 用户可见 bug ，而不是 研发可复现的崩溃。
这对于稳定性指标（crash 率下降），看似有好处，但实际上可能导致 用户体验更差，研发也更难排查问题。
四、崩溃率 vs 稳定性：Return 和 CHECK 的权衡
在工程实践中，我们必须明确：
-
崩溃率降低 ≠ 稳定性提升
-
关键在于 是否能继续安全执行
我们来对比：
| 场景 | 使用 CHECK | 使用 return |
|---|---|---|
| 必要资源缺失（如 ICU 数据、核心 UI XML） | 立即崩溃，易于定位问题 | 可能黑屏、功能残缺，用户可见异常 |
| 可选功能缺失（如某个实验性模块文件） | 不建议 CHECK，影响整体稳定性 | return 更合理，降级执行 |
| 开发/调试阶段 | CHECK 更利于暴露问题 | return 可能掩盖 bug |
| 线上用户体验 | 崩溃率升高，定位快 | 崩溃率降低，但潜在 bug 难发现 |
所以，CHECK 和 return 的取舍，本质是 在开发效率和用户体验之间做平衡。
五、实战案例：ICU 数据初始化
再看一个浏览器启动过程的例子：
bool InitializeICUFromDataFile() { LazyInitIcuDataFile(); bool result = InitializeICUWithFileDescriptorInternal(g_icudtl_pf, g_icudtl_region); // 省略修复逻辑... #if !BUILDFLAG(IS_CHROMEOS) CHECK(result); #endif return result; } 5.1 为什么要 CHECK(result)
ICU（International Components for Unicode）库是浏览器处理多语言文本的底层依赖：
-
URL 编解码
-
字符串归一化
-
字体渲染
如果 result == false，意味着 ICU 数据加载失败，浏览器将 无法正常显示文字，后续所有逻辑都是"废的"。
这种情况不可能通过 return 优雅降级，因此必须 硬崩溃。
5.2 线上优化的方式
有些厂商会加 修复逻辑：
-
如果文件损坏，尝试复制备份文件或重新下载。
-
只有在修复仍失败时，才触发
CHECK。
这样既保留了问题定位能力，也避免了因文件损坏导致的大规模崩溃。
六、Return vs CHECK 的取舍标准
结合浏览器内核开发经验，我总结了一套实践标准：
-
核心依赖缺失（必须）
-
比如 ICU、核心 DLL、主进程资源
-
必须
CHECK，否则继续执行毫无意义
-
-
关键路径但可恢复（尝试修复后 CHECK）
-
比如 UI skin、配置文件
-
可以先尝试 fallback/修复，最后再
CHECK
-
-
非关键路径（直接 return）
-
比如实验性模块、日志收集、辅助功能
-
用
return避免线上崩溃率增加
-
-
Debug 阶段优先 CHECK，Release 阶段视情况降级
-
开发时暴露问题
-
发布时保障用户体验
-
七、稳定性优化的工程思考
7.1 崩溃率指标要结合 "可用性"
-
单纯追求 crash 率下降 并不科学
-
更重要的是用户是否能 完成主要功能
-
如果 return 导致浏览器无法启动，虽然 crash 率下降，但用户留存反而下降
7.2 崩溃收敛要和监控系统结合
-
通过 Crashpad 或 Breakpad 收集崩溃堆栈
-
配合日志系统判断是 偶发 bug 还是 环境问题
-
对于外部文件缺失类问题，可以考虑 自愈机制（repair）
7.3 CHECK 的位置很关键
-
CHECK 应该放在 错误首次被发现的位置，而不是后面调用处
-
否则会让堆栈看起来和实际问题无关，增加排查难度
八、总结
本文通过分析 CHECK 和 return 的区别，结合浏览器内核中的 UI 资源加载 和 ICU 初始化 两个案例，说明了它们在 线上崩溃率优化 中的不同作用：
-
CHECK：快速失败，便于定位核心问题，但可能提高 crash 率
-
return：避免崩溃，提升稳定性，但可能掩盖严重问题
最佳实践是：
-
核心依赖：必须 CHECK
-
可修复：修复失败后 CHECK
-
非关键路径：return
崩溃率优化的目标不只是数字下降，而是 既能快速定位问题，又能保障用户体验。
这正是工程实践中的智慧所在。