std::shared_mutex适合读多写少场景，允许多读单写；ConcurrentQueue+线程池实现请求合并，双阈值触发；list::splice零拷贝合并；协程需注意调度上下文与TLS安全。
std::shared_mutex 适合读多写少的请求合并场景
当多个线程频繁查询共享配置或缓存（比如模型参数、路由规则），但修改极少时，std::shared_mutex比std::mutex更合适。它允许多个线程同时读，只在写时独占——这能避免“合并请求”过程中因反复加锁导致的排队阻塞。
常见错误是误用std::shared_lock去保护写操作，结果触发未定义行为；或者在写入前没调用lock()而直接unlock()，引发崩溃。
- 读操作用
std::shared_lock<:shared_mutex></:shared_mutex>，开销接近无锁 - 写操作必须用
std::unique_lock<:shared_mutex></:shared_mutex>，且确保写完才释放 - 若合并逻辑本身耗时（如解析 JSON、校验签名），别把整个处理塞进临界区，应先拷贝数据再处理
用 ConcurrentQueue + 线程池做批量请求合并
真正需要“合并”的不是数据本身，而是对后端服务的调用频次。比如每 100ms 内收到 23 个 get_user 请求，与其发 23 次 RPC，不如攒成一个 get_users([id1,id2,...]) 批量调用。
关键不在队列实现，而在“何时触发合并”：太早则吞吐低，太晚则延迟高。实践中建议用双阈值控制——达到数量（如 16 个）或超时（如 50ms）任一条件即触发。
立即学习“C++免费学习笔记（深入）”；
-
ConcurrentQueue的try_pop()必须配合循环使用，不能只调一次就放弃 - 工作线程从队列取任务后，要主动 sleep 一小段时间（如
std::this_thread::sleep_for(10ms)），给新请求“入队窗口” - 避免在合并函数里直接 new 对象——高频合并下容易触发内存抖动，改用对象池或栈上分配
std::list::splice 是零拷贝合并链表的唯一安全方式
如果合并的是待处理请求列表（比如 std::list<request></request>），别用 insert 或 merge，它们会复制节点或重排迭代器。只有 splice 能把另一个 list 的节点指针直接“剪切”过来，不调构造/析构，也不影响原 list 中元素的地址。
典型陷阱是传入已失效的迭代器：比如 list2.begin() 在 splice 前被 erase 过，或者 list2 已被 move 走。此时行为未定义，调试极难定位。
- 合并单个节点用
splice(pos, other, it)，注意it必须指向other - 合并区间用
splice(pos, other, first, last)，区间是左闭右开[first, last) - 若目标 list 和源 list 是同一个对象，
splice仍合法，但需确保pos不在[first, last)内
协程 + awaitable 合并请求容易忽略调度上下文
C++20 协程能自然表达“等待一批请求凑齐”，但 co_await 后的执行位置不一定是原线程。比如你在 IO 线程里启动协程，合并完成后回调却跑到线程池里——若后续操作依赖 TLS 变量或线程局部资源，就会出错。
这不是协程本身的 bug，而是调度器没显式绑定上下文。很多开源库（如 libunifex、cppcoro）默认使用线程池调度，需手动 wrap 成 inline_scheduler 或指定执行器。
- 不要在协程里直接访问
thread_local变量，除非你 100% 控制调度策略 - 合并后的批量结果若需返回给原始请求者，得保存其
std::coroutine_handle或 promise 对象，不能只存裸指针 -
std::jthread比std::thread更安全，但协程不自动关联 jthread 生命周期，仍需手动管理取消
