标准库多线程组件需谨慎使用：std::thread析构前必须join或detach，否则terminate；std::mutex须用lock_guard等RAII封装保证异常安全；std::atomic不保证复合操作原子性；std::async默认可能延迟执行，需显式指定launch::async确保并发。
标准库的 std::thread、std::mutex、std::atomic 和 std::async 足够应对绝大多数多线程场景，但直接裸用容易出错——尤其是资源释放顺序、异常安全和竞态边界没理清时。
std::thread 构造后必须显式管理生命周期
构造 std::thread 对象后，它就拥有了一个关联的执行线程。如果该对象在析构前既未调用 join() 也未调用 detach()，程序会直接调用 std::terminate() 终止，且不抛异常、不打印堆栈。
常见错误写法：
void worker() { /* ... */ }
void bad_example() {
std::thread t{worker}; // 构造成功
// 忘记 join/detach → 析构时 terminate!
}正确做法：
立即学习“C++免费学习笔记（深入）”；
- 明确线程归属：需要等待结果 → 用
join()；后台长期运行 → 用detach()（但要确保所捕获变量的生命周期足够长） - 推荐封装：用 RAII 类（如自定义
scoped_thread）强制绑定join()或detach() - 避免临时对象绑定：不要写
std::thread{worker}().join();—— 临时对象在语句末就析构，join()调用无效
std::mutex 不能复制，且 lock/unlock 必须成对
std::mutex 是非可复制、非可移动类型，只能通过引用或指针共享。手动调用 lock() 和 unlock() 极易遗漏（尤其在有异常分支的函数中）。
典型问题：
- 忘记
unlock()导致死锁 - 异常路径跳过
unlock()，后续线程永远阻塞 - 跨作用域重复
lock()（同一线程对同一 mutex 多次加锁 → 未定义行为）
务必使用 RAII 封装：
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
std::mutex mtx;
void safe_access() {
std::lock_guard<std::mutex> lk{mtx}; // 构造即 lock，析构即 unlock
// 即使这里 throw 异常，lk 析构仍会 unlock
do_something();
}注意：std::lock_guard 不支持递归加锁；如需同一线程多次进入临界区，改用 std::recursive_mutex + std::lock_guard。
共享变量读写必须同步，atomic 不等于万能
即使只读或只写单个内置类型（如 int），只要多个线程访问同一对象，且至少一个为写操作，就必须同步。编译器重排、CPU 乱序、缓存不一致都可能导致未定义行为。
std::atomic 可解决简单标量的无锁读写，但要注意：
- 默认内存序是
std::memory_order_seq_cst，性能开销略高；高频场景可降级（如用relaxed做计数器，acquire/release做同步点） -
std::atomic不保护复合操作：比如counter++是读-改-写三步，必须用fetch_add()等原子操作，而非普通赋值 - 结构体/类不能直接 atomic 化，除非是 trivially copyable 且满足对齐等限制；否则仍需 mutex 保护
std::async 默认可能不启动新线程
std::async 的启动策略由 std::launch 参数控制，默认是 std::launch::deferred | std::launch::async，意味着实现可选择延迟执行（类似惰性求值），直到你调用 get() 或 wait() 才真正运行 —— 这不是 bug，是标准允许的行为。
后果：
- 你以为并发执行，实际是串行延迟执行
- 若只创建
std::future但不调用get()/wait()，延迟任务永远不会跑
确保并发执行的方法：
auto f = std::async(std::launch::async, []{ return heavy_work(); }); // 显式指定 async
// 此时线程立即启动，不依赖 get() 触发另外注意：std::future 析构时若未取值，会阻塞等待完成 —— 这容易导致意外的主线程挂起，尤其在容器里存了一堆 future 却忘了遍历 get()。
多线程最难的从来不是“怎么启动线程”，而是“哪些数据被谁在什么时刻访问”。标准库组件只是工具，真正决定正确性的，是你对共享状态边界的判断精度，以及对每处 lock、atomic、join 背后隐含约束的清醒认知。
