cerr用于紧急错误信息，不缓冲、立即输出；clog用于常规日志，带缓冲、可重定向；二者均不应替代cout作用户输出。
cerr 适合输出紧急错误信息
程序崩溃前必须看到的信息，就该走 cerr。它不缓冲，每次写入立刻刷到终端（或重定向目标），哪怕后面马上发生段错误，前面那句 cerr << "Null pointer dereference" 也能被你看见。
常见错误现象：用 cout 打印错误但程序一崩就啥都看不到；或者日志里缺了最后几条关键报错。
- 典型场景：断言失败、资源分配失败、参数校验不通过
- 不要用于高频日志——它绕过缓冲，I/O 开销大
- 不能被静默丢弃：即使重定向到文件，
cerr默认仍连着 stderr，多数 shell 和日志收集器会单独捕获它
clog 适合输出常规运行日志
clog 是带缓冲的，行为接近 cout，但语义上专为日志设计。它默认也输出到 stderr，但可以安全重定向到文件，且不会因程序异常退出而丢失大量内容（只要缓冲区在退出前被刷新）。
常见错误现象：用 cout 打日志，结果和正常输出混在一起，grep 不出来；或重定向时日志意外消失。
立即学习“C++免费学习笔记（深入）”；
- 典型场景：模块初始化完成、请求进入/退出、计时打点、调试开关开启时的上下文输出
- 注意刷新时机：程序非正常终止（如
abort()或信号 kill）时，未 flush 的clog内容会丢失 - 可手动控制：需要强一致性时加
clog.flush()，或在关键节点后用<< std::endl（会触发 flush）
cerr 和 clog 都不该用于用户可见输出
用户界面、提示文字、格式化结果这些，应该交给 cout。把 cerr 或 clog 当成“系统通道”：运维查问题、CI 检测失败、监控抓 error pattern，都依赖它们的语义明确性和隔离性。
容易踩的坑：
- 把
clog << "Processing item: " << i << "\n"当作 printf 用，结果日志和 stdout 顺序错乱（因缓冲差异） - 重定向脚本里只捕获 stdout，漏掉
clog输出（虽然默认到 stderr，但没显式重定向就可能被忽略） - 在多线程中无保护地往
clog写，导致日志行粘连（cerr同样存在这问题，但它更常被加锁封装）
重定向时 clog 比 cerr 更灵活
clog 可以像 cout 一样被替换成文件流：clog.rdbuf(file_stream.rdbuf())，而 cerr 虽然也能换，但它的无缓冲特性在文件写入时反而拖慢性能，还失去“紧急提示”的原始意义。
实际选择依据：
- 要进 syslog 或 ELK？用
clog+ 自定义streambuf - 只想在终端看一眼就关？
cerr最省心 - CI 流水线里判断失败原因？确保关键错误走
cerr，其余诊断信息走clog，再用不同 grep 模式分离
