std::endl 会清空缓冲区而 n 不会，前者等价于输出 n 后调用 std::flush，后者仅为换行字符；常见问题包括输出延迟、“卡住”及重定向时失效。
std::endl 会清空缓冲区，n 不会
这是最常被误解的一点：很多人以为 std::endl 只是换行，其实它等价于输出一个 n 再调用 std::flush。也就是说，它强制把缓冲区里还没写出去的内容立刻刷到输出设备（比如终端或文件）。而 n 单纯是字符，不触发刷新。
常见错误现象：
程序运行没报错，但输出“卡住”、延迟出现，尤其在重定向到文件或管道时；或者调试时加了 std::cout 能看到日志，换成 <code>"heren" 就看不到——大概率是缓冲区没刷。
- 使用场景：交互式命令行工具、需要实时可见日志的调试阶段、写入日志文件且要求每条立即落盘
- 性能影响：频繁用
std::endl会显著拖慢 I/O，尤其是大量小输出时（每次都要系统调用 flush） - 兼容性无差异：所有标准 c++ 编译器行为一致
手动清空缓冲区用 std::flush 或 std::cout.flush()
如果你只要刷新、不要换行，就别用 std::endl。直接上 std::flush 更准确，也更易读意图。
示例：
立即学习“C++免费学习笔记（深入）”；
std::cout << "Processing..." << std::flush; // 不换行，但立刻显示 // ... 做些耗时操作 std::cout << " done.n";-
std::flush是操纵符（manipulator），用于流插入操作符链中 -
std::cout.flush()是成员函数，效果相同，但不能嵌在 - 注意：对输入流（如
std::cin）调用flush()是未定义行为，别试
全局禁用缓冲？用 std::ios_base::sync_with_stdio(false) 但慎用
这不是“清空缓存”，而是切换底层同步机制。默认 C++ 流和 C 标准库流（printf/scanf）是同步的，保证混用时不乱序。关掉后，C++ 流自己管理缓冲，速度可能提升，但：
- 一旦调用过
printf或scanf，再关同步就无效（且不会报错） - 关同步后，
std::cin和std::cout的缓冲行为更“激进”，n更难触发自动刷新 - 关同步 + 不手动 flush → 日志消失、交互卡死，是线上调试高频坑
所以除非你明确只用 C++ 流、且追求极致 I/O 吞吐（如算法竞赛），否则别动它。
文件流和字符串流的缓冲行为不一样
std::ofstream 和 std::ostringstream 默认不关联终端，因此它们的 std::endl 虽然仍会 flush，但实际效果不明显——因为目标不是实时设备。而 std::ostringstream 甚至没有“物理缓冲区”概念，flush 对它什么也不做。
-
std::ofstream写文件时，std::endl会 flush，但操作系统还可能缓存磁盘写入（要真正落盘得用.flush()+fsync等系统调用） -
std::ostringstream中用std::endl纯属冗余，只加n就够了 - 判断是否需要 flush，关键看目标：终端？网络 socket？文件？——而不是流类型本身
C++ 缓冲行为不是玄学，但它依赖目标设备、同步设置、甚至之前是否混用过 C 函数。最容易被忽略的是：你以为 std::endl 只是换行，其实它悄悄干了系统调用；而你以为 n 安全，它却可能让你的日志永远出不来。