一、前言

在大型 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; }