std::thread构造函数立即按值拷贝参数并应用std::decay_t，不转发引用；需用std::ref/std::cref显式传递引用，避免悬空或误移。
std::thread 构造函数会立即拷贝参数，不是转发
std::thread 的构造函数模板接受可调用对象和任意数量的参数，但它对参数的处理是「按值拷贝」，而非完美转发。这意味着你传进去的左值会被拷贝（如果可拷贝），右值也会被移动（如果可移动），但绝不会以引用方式保存——哪怕你显式写了 & 或 &&，也会在构造时被强制衰变（decay）并拷贝。
常见错误现象：传入局部变量的引用，线程里访问时已析构；或传入 std::move 后原对象被移走，但线程实际拿到的是拷贝/移动后的副本，不影响逻辑——但容易误以为“引用传进去了”。
- 所有参数都会经过
std::decay_t处理：去掉引用、const/volatile 限定符，数组转指针，函数类型转函数指针 - 拷贝行为发生在构造
std::thread对象时，不是在线程启动时 - 即使 lambda 捕获了引用，
std::thread构造时只拷贝 lambda 对象本身，不干涉其捕获方式
std::ref 和 std::cref 是绕过衰变的唯一标准办法
如果你真需要在线程中操作原始对象（比如修改某个局部变量），必须显式包装成 std::ref(x) 或 std::cref(x)。它们是特化类型，重载了 std::decay_t 的行为，使得 std::thread 构造时保留引用语义（内部存储的是指针）。
使用场景：多个线程需共享并修改同一容器；回调中需更新外部状态计数器；避免大对象不必要的拷贝。
立即学习“C++免费学习笔记（深入）”；
-
std::ref(x)要求x是左值，且类型必须可赋值（因为线程内可能通过引用修改） -
std::cref(x)生成 const 引用，适合只读场景，更安全 - 不能对临时量（如
std::ref(std::string("hi"))）用std::ref，生命周期无法保证
#include#include int main() { int x = 42; std::thread t([](int& r) { r = 100; }, std::ref(x)); // ✅ 正确：x 在线程中被修改 t.join(); std::cout << x << "\n"; // 输出 100 // ❌ 错误写法（编译失败）： // std::thread u([](int& r) { r = 200; }, x); // x 是 int，不是 int&，类型不匹配 }
lambda 捕获 vs. thread 参数传递：别混为一谈
lambda 捕获列表（[&], [=], [x]）控制的是 lambda 对象**内部如何持有变量**；而 std::thread 构造函数的参数决定的是**哪些值被传入线程执行体**。两者独立作用，但常被误认为等价。
例如：你写 std::thread{[&](){ ... }}，这个 lambda 的 & 只影响它内部能否访问外部变量，但 lambda 本身仍被 std::thread 拷贝 —— 如果它捕获了局部变量的引用，而该局部变量在 std::thread 构造后就销毁了，那线程运行时就是悬空引用。
- 推荐显式捕获 + 显式传参，避免隐式
[&]带来的生命周期风险 - 若需传对象又不想拷贝，优先考虑
std::ref+ 值传递，而非依赖捕获 - 移动捕获（
[x = std::move(y)]）是安全的，因为移动发生在构造 lambda 时，与 thread 构造无关
std::move 传给 std::thread 并不改变“拷贝语义”的本质
对右值调用 std::move 后传给 std::thread，只是让 std::thread 构造时尝试移动该参数（如果类型支持移动构造）。但它仍是“把那个值搬进来”，不是“把引用传进去”。很多人以为 std::move(obj) 就能让线程直接操作原 obj，这是错的。
性能影响：对不可移动类型（如某些 legacy 类），std::move 不起作用，仍会触发拷贝；对可移动类型，能避免深拷贝，但内存分配/释放开销仍在构造时发生。
- 传
std::move(some_string)→std::thread内部 string 成员被移动构造，原some_string置为空 - 传
std::ref(some_string)→std::thread内部存的是指向some_string的指针，原对象保持不变 - 传两者混合（如
std::thread{f, std::move(a), std::ref(b)}）完全合法，各自按规则处理
detach() 时，没人帮你检查这点。 
