std::thread的参数会被拷贝到新线程吗？该机制存在哪些设计疑问？

首先澄清：不存在每次调用都触发的潜在竞态 #

你观察到的“参数在新线程上下文中完成最终传递”，是std::thread的标准化设计，从来没有“每次构造都埋着竞态”的问题。触发未定义行为的场景，全部是用户主动传递了悬空的指针/引用、且被引用对象在线程实际拿到参数前就已析构的情况。
先把规则的精确边界说清楚，避免常见认知偏差：

按照C标准的定义，std::thread构造函数收到实参后，会立即在原线程的上下文中，把所有传入的实参做std::decay处理，转换成可存储的纯值类型，存到thread对象的内部存储结构中。这一步的拷贝/移动操作，是在thread构造函数返回前就完成的，根本不存在“把实参拷贝完全延后到新线程启动”的情况。
很多读者对《C Concurrency in Action》中的描述有误解，以为值类型的实参拷贝也会被延后到新线程启动后、从原作用域的lvalue上现拷——实际上值类型的拷贝在thread构造函数返回前就已经完成了，哪怕原lvalue立刻析构，新线程用到的也是thread内部存好的副本，完全不存在安全问题。
真正延后到新线程执行上下文的步骤，只有最后一步：从thread的内部存储中，把已经存好的实参副本，按目标函数的形参要求，移动/拷贝到线程函数的调用栈上，完成函数调用。真正触发未定义行为的场景，全部是decay后存储的内容是指针/引用（比如传入裸指针、传入std::ref包裹的对象）、但被指向/引用的原对象在新线程拿到参数前就已析构的情况，和值类型的拷贝时机没有关系。

为什么不把最后一步的“函数实参传递”也放在原线程完成？ #

这不是设计疏忽，是多重现实约束决定的：

• 操作系统的权限边界限制：新线程的调用栈是由内核在创建线程时分配的内存区域，在新线程启动前，这段栈内存对原线程是没有写入权限的（就算有权限，栈的地址布局、栈指针位置都是新线程初始化流程自己维护的，原线程提前写入的内容根本没法被新线程正确识别）。你根本不可能在原线程上下文里，直接把参数写到新线程的栈帧上完成函数调用准备——这是操作系统层面的硬限制，不是C++标准能绕过的。
• 性能与快速启动的设计目标：std::thread的构造函数要求尽可能快速返回，把线程创建的开销压到最低。如果把所有参数的隐式类型转换、大对象的拷贝/移动全部提前在原线程做，那会把大量和线程启动无关的操作时间，绑定到调用thread构造函数的原线程上，拖慢原线程的执行节奏。而把参数传递的最后一步放到新线程上下文里完成，完全不会影响原线程的执行效率——毕竟新线程本来就需要自己的初始化流程，顺带完成参数解包的开销，是完全可接受的。
• 完美转发的语义一致性：std::thread是通用的异步调用接口，需要支持任意可调用对象、任意参数类型（包括只可移动类型、带cv限定的类型、需要隐式转换的类型）。如果强行要求在原线程就完成全部参数构造，会把参数构造时的异常、参数的生命周期管理全部绑定到原线程的异常语义里，违背了异步执行的解耦目标。

常见的UB触发场景（也就是你担心的风险来源） #

风险从来不是来自参数拷贝本身，而是来自用户自己传递了悬空的引用/指针：

• 构造完thread对象后，没有等待线程完成，就让被thread捕获的栈上对象出作用域析构：比如在函数内部写int local = 42; std::thread t([&local]{ use(local); }); 函数直接return，local析构，新线程还在读已经销毁的栈内存。
• 给std::thread传入std::ref包裹局部变量，却没有保证局部变量的生命周期覆盖整个线程执行周期。
• 把指向堆上/栈上对象的指针作为实参传给thread，却在新线程解引用指针前就把指向的对象释放了。

只要你传递给thread的实参，本身就是独立拥有所有权的副本，不存在任何外部悬空引用，整个参数传递流程是完全线程安全的，不存在你担心的“每次调用都有竞态”。

内容的提问来源于stack exchange，提问作者Vasyl Demianov