C++线程函数参数用const std::stop_token&还是std::stop_token？

clang-tidy给出的“按值传参仅作const使用时改为const引用”是通用性能优化规则，但这个规则不适用于std::stop_token，这也是几乎所有官方、社区示例都选择按值传递的原因。

首先明确两种常见的函数签名写法：

// 写法1：按值传递
void f(std::stop_token st) {};
// 写法2：const引用传递
void f(const std::stop_token& st) {};

两者的实际差异和按值传递的合理性可以归纳为三点：

• std::stop_token本身是极轻量的句柄类型。它的内部仅持有一个指向线程停止状态共享控制块的指针，复制操作仅需要拷贝指针、对控制块的引用计数做一次原子递增，开销和复制一个std::shared_ptr相当，完全不属于clang-tidy优化规则针对的“大对象高成本复制”场景，警告属于通用规则未适配标准库特殊类型导致的误报。
• 按值传递是触发std::jthread自动注入stop_token的必要条件。C++标准明确规定：只有当线程入口可调用对象的参数列表中存在按值接收的std::stop_token类型参数时，std::jthread的构造函数才会在启动线程时自动把自身关联的stop_token传入函数。如果参数写为const引用，SFINAE检查会判定该函数不需要stop_token，不会执行自动注入逻辑，函数根本拿不到对应的停止信号，这是示例代码统一用按值写法的最核心原因。
• 按值传递天然规避生命周期问题。如果后续需要在函数内给传入的stop_token注册std::stop_callback、或者把stop_token存储到函数外异步使用，按值拿到的st本身就是独立持有引用计数的合法句柄，不需要额外做复制操作就能安全使用；如果是const引用传入，只要引用绑定的原始stop_token被销毁，后续访问就会出现悬垂引用的未定义行为。

针对“确定传入的stop_token来自std::jthread时，两种写法是否有实际影响”的问题：

如果你的函数同时满足两个前提：1. 永远不会直接作为std::jthread的线程入口函数使用，不需要依赖自动注入stop_token的逻辑；2. 函数内部仅在当前调用栈生命周期内调用stop_requested()等const成员方法，不会存储token、不会注册回调，那两种写法不存在功能差异，const引用的写法确实能省掉一次原子引用计数增减的开销。但这个开销在绝大多数业务场景下完全无法被感知，为了代码通用性、避免踩中自动注入失效的坑，社区默认约定统一按值传递std::stop_token，对应的clang-tidy警告可以针对该类型单独抑制，不需要修改代码。

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