std::ref不能直接传给std::thread构造函数，因其参数被decay_t处理为副本，导致子线程中std::reference_wrapper内部引用可能悬垂；正确做法是确保被引用对象生命周期≥线程执行期，或改用lambda显式捕获引用。
std::ref 为什么不能直接传给 std::thread 构造函数
直接把 std::ref(x) 传给 std::thread，线程函数里拿到的往往不是你期望的引用——而是被拷贝构造出的一个临时 std::reference_wrapper 对象，其内部引用在子线程中可能指向已销毁的栈变量，或者因移动语义意外失效。
根本原因在于：std::thread 的参数会被**完美转发并存储为副本**（调用 decay_t 后类型），而 std::reference_wrapper 的拷贝是安全的，但它包装的原始引用生命周期必须由调用方严格保证。
- 常见错误现象：
std::thread t(func, std::ref(x));中x是局部变量，主线程函数返回后x被析构，子线程访问触发未定义行为 - 正确做法：确保被引用对象的生命周期 >= 线程执行期；且显式用
std::ref包装，避免被误推导为值传递 - 不要写
std::thread t(func, x);期望它自动按引用传——C++ 默认永远按值传递可复制对象
std::ref + lambda 捕获是更安全的替代方案
比起裸传 std::ref 给函数指针，用 lambda 显式捕获引用更直观、生命周期更可控，也规避了 std::reference_wrapper 的隐式转换陷阱。
int value = 42;
std::thread t([&value] {
value *= 2; // 直接读写原始变量
});
t.join();
- 适用场景：线程逻辑简单、只操作少数几个变量，且你能明确控制这些变量的生存期
- 注意：用
[&value]而非[=]或[&]——前者精准，后者可能意外捕获无关变量或引发悬垂引用 - 如果变量是局部对象，lambda 必须在该对象作用域内启动线程，并确保在线程结束前不退出作用域
std::ref 在线程函数参数中真正起作用的典型用法
当线程函数是普通函数或可调用对象（非 lambda），且需要接收多个参数，其中某些必须以引用方式修改时，std::ref 才是必要手段。
立即学习“C++免费学习笔记（深入）”；
void increment(int& a, int& b) {
++a; ++b;
}
int x = 10, y = 20;
std::thread t(increment, std::ref(x), std::ref(y));
t.join(); // x == 11, y == 21
- 关键点：函数签名必须声明为引用形参（
int&），否则std::ref无法解包成左值引用 - 若函数形参是
const int&，也可用std::cref(x)，语义更清晰 - 不要对右值用
std::ref：比如std::ref(42)编译失败，因为右值不能绑定到非 const 引用 - std::thread 内部会调用
std::reference_wrapper::get()来取出原始引用，所以函数内看到的就是原变量本身
std::ref 和 move 的混用极易出错
一旦在 std::thread 参数中同时出现 std::ref(x) 和 std::move(y)，顺序和所有权边界就变得脆弱。编译器不会报错，但运行时行为难以预测。
- 典型坑：
std::thread t(func, std::ref(obj), std::move(data));中，若func先修改obj再使用data，而data已被移走，可能 crash - 更稳妥的做法：把需移动的对象先移到线程私有结构体中，再用
std::ref传结构体引用；或统一用 lambda 捕获，显式控制 move 和引用时机 - std::ref 本身不可移动（它是轻量包装，拷贝开销极小），但包裹的对象是否可移动、是否已被移动，得靠程序员自己盯住
最常被忽略的一点：std::ref 只解决“怎么传引用”，不解决“引用谁、谁活着、谁负责析构”——这三件事仍得你亲手画清楚生命周期图。
