优先用 lambda，避免 std::bind 绑定成员函数启动线程；若必须用 std::bind，须确保对象生命周期长于线程执行期，否则易因悬空指针导致崩溃。
直接结论：优先用 lambda，避免 std::bind 绑定成员函数启动线程；若必须用 std::bind，必须确保对象生命周期长于线程执行期，否则极易崩溃。
为什么 std::bind 绑定成员函数启动线程容易出错
最常见错误是传入裸指针（如 &obj）后，obj 在线程真正执行前就已析构。此时 std::thread 调用的仍是悬空指针，行为未定义——大概率 crash，且难以复现。
-
std::bind(&MyClass::func, &obj, args...)只拷贝指针值，不管理obj生命周期 - 若
obj是栈对象、或被提前reset()的智能指针所指向，绑定后的可调用对象仍会尝试访问已释放内存 - 错误现象常表现为：程序偶发崩溃、访问违规（Windows）、segmentation fault（Linux），堆栈中出现
MyClass::func但this为非法地址
用 lambda 启动线程更安全、更直观
lambda 天然支持捕获，能明确控制对象所有权语义。只要捕获方式选对，生命周期问题基本可控。
- 捕获
[this]：适用于this所指对象确定在线程结束前不会销毁（如线程在类内启动且与对象同生命周期） - 捕获
[ptr = shared_from_this()]：适用于继承自std::enable_shared_from_this的类，确保对象至少在线程运行期间存活 - 捕获
[obj = std::move(obj_copy)]：若需在线程中独占使用对象副本，用移动捕获避免意外共享 - 避免
[&]或[&obj]：引用捕获在线程异步场景下几乎总是危险的
示例：
立即学习“C++免费学习笔记（深入）”；
struct Worker : std::enable_shared_from_this<Worker> {
void doWork(int n) { /* ... */ }
void startAsync() {
auto self = shared_from_this();
std::thread([self, n = 42]() { self->doWork(n); }).detach();
}
};
std::bind 不是不能用，但要绕过它的隐式拷贝陷阱
如果因历史代码或接口约束必须用 std::bind，就不能依赖裸指针。核心原则：让绑定对象自己持有生存期控制权。
- 用
std::shared_ptr<T>替代T*或T&：如std::bind(&T::f, ptr, _1)，其中ptr是std::shared_ptr<T> - 禁用
std::ref/std::cref：它们只解决参数传递时的引用语义，不延长对象生命周期，对成员函数绑定无实质帮助 - 慎用对象值绑定（
std::bind(&T::f, obj, _1)）：这会拷贝整个对象，若obj不可拷贝、或拷贝代价高、或需修改原对象状态，则完全不可行 - 注意
std::thread构造时的右值转发：绑定结果需可移动，否则编译失败；lambda 默认可移动，std::bind返回类型较重，某些旧编译器可能推导失败
真正容易被忽略的点：线程 detach 之后的失控风险
无论用 std::bind 还是 lambda，只要调用了 .detach()，你就放弃了对该线程的控制权。此时对象生命周期是否安全，不再由你显式检查，而完全依赖捕获/绑定方式是否真正闭环。
更稳妥的做法是：把 std::thread 成员变量 + join() 放进类里管理，或用 std::jthread（C++20）自动处理；若必须 detach，请确保所有捕获对象都通过 shared_ptr 持有，且没有其他路径提前释放该 shared_ptr。
