std::osyncstream 不保证线程安全，仅提供缓冲区独占与析构时原子刷出；若多个 osyncstream 绑定同一 ostream（如 cout）且无额外同步，输出仍会交错。
std::osyncstream 本身不保证线程安全，它只提供「缓冲区独占 + 自动刷出」机制；真正防止输出交错，靠的是构造时传入的 std::basic_osyncstream 底层绑定的 std::ostream& 是否被其他线程同时写入 —— 如果多个 std::osyncstream 同时绑定到同一个 std::cout，且未加锁，依然会交错。
为什么 std::osyncstream 构造后立即刷出？
它在析构时调用 emit()，把本地缓冲区内容原子地写入绑定的 ostream（如 std::cout）。这个“原子写入”不是指线程安全，而是指：一次 emit() 调用对底层流的写操作是完整、不可分割的 —— 但前提是，没有别的线程正直接写这个流。
- 构造
std::osyncstream会分配独立缓冲区，隔离当前线程的格式化输出 - 所有 std::cout
- 离开作用域时自动调用
emit()，将整块缓冲内容以单次rdbuf()->sputn()写入目标流 - 如果目标流（如
std::cout）本身被其他线程直接调用operator，<code>emit()和那个直接写入就可能交错
std::osyncstream 必须搭配 std::cout 的线程同步使用
单独用 std::osyncstream 无法解决竞争，必须确保：同一时间，只有一个线程在向底层 std::ostream 执行写操作（无论是通过 std::osyncstream::emit() 还是直接
- 推荐方式：所有线程统一通过
std::osyncstream写std::cout，且不混用裸std::cout - 不推荐方式：部分线程用
std::osyncstream，部分用std::cout —— 交错必然发生 - 更稳妥方式：配合
std::mutex锁住std::cout，再用std::osyncstream（冗余但安全） -
std::osyncstream不拥有流，也不管理流的生命周期；绑定后不能移动/复制，仅限栈上短生命周期使用
一个典型安全用法示例
下面代码中，每个线程都只通过 std::osyncstream 输出，且不直接碰 std::cout：
立即学习“C++免费学习笔记（深入）”；
void worker(int id) {
std::osyncstream os{std::cout}; // 绑定到 std::cout
os << "Thread " << id << " starts\n";
os << "Thread " << id << " finishes\n";
// 离开作用域，自动 emit()，整行写入 cout
}
int main() {
std::vector<std::thread> threads;
for (int i = 0; i < 3; ++i) {
threads.emplace_back(worker, i);
}
for (auto& t : threads) t.join();
}
输出不会出现 “Thread 1 start\nThread 2 st” 这类字符级交错，但依然可能出现两行顺序颠倒（如 T2 先 finish、T1 后 start），因为不同线程的 emit() 调用仍受调度影响 —— std::osyncstream 只保单次 emit 原子，不保多线程 emit 的全局顺序。
容易忽略的关键点
很多人以为 std::osyncstream 是“线程安全的 cout”，其实它只是个带自动刷出的同步包装器。真正易错的地方在于：
- 误以为绑定后
std::cout就自动线程安全了 —— 它没有加锁，也没拦截裸调用 - 在 lambda 或异步任务里捕获
std::osyncstream并延长其生命周期，导致绑定流被提前析构 - 跨 DLL 边界传递
std::osyncstream（ABI 不稳定，C++20 实现尚未完全统一） - 对
std::ofstream使用std::osyncstream时，忘了文件流本身不支持多线程并发写（即使加 syncstream，也要自己同步）
