std::semaphore 构造时 count 应设为实际最大并发数，如数据库连接池限5路则用 std::semaphore{5}，模板参数优选 short；需捕获 acquire() 异常，避免与 mutex 误序混用，且环境须满足 C++20 及对应标准库版本要求。
std::semaphore 构造时 count 参数设多少才对
信号量的初始计数值直接决定最多能同时进入临界区的线程数。设为 N，就允许最多 N 个线程通过 acquire()；设错会导致并发数失控或完全阻塞。
常见错误是设成 0（所有线程卡死）或远大于实际需要（失去限流意义）。比如控制数据库连接池最大 5 路并发，就该写 std::semaphore<short>{5}</short> —— 注意模板参数类型必须能容纳你的初值，short 足够且更省内存。
- 别用
int或size_t模板参数去扛小数值，标准库实现可能对底层原子操作有对齐/宽度要求 - Windows 上某些 libc++ 实现对大数值（如 >32767）支持不稳，保守起见控制在
short范围内 - 构造后不能动态改 count，要变限流数就得重建信号量（通常不推荐）
acquire() 和 try_acquire() 别混用导致逻辑断裂
acquire() 是阻塞式，try_acquire() 是非阻塞式返回 bool。混用时容易漏掉失败路径，尤其在超时控制场景下。
比如你想等最多 100ms 获取许可，但直接写 if (!sem.try_acquire()) { std::this_thread::sleep_for(100ms); } 是错的——这根本没重试，也没释放机会，还浪费了等待时间。
立即学习“C++免费学习笔记（深入）”；
- 真要带超时，得自己循环 +
try_acquire()+std::this_thread::yield()，或者用封装好的辅助函数 -
acquire()可能抛std::system_error（如系统资源耗尽），必须捕获，不能假设它“一定成功” - 别在析构或异常路径里忘记
release()，否则信号量永久泄漏，程序越跑越慢
和 std::mutex 混用时注意粒度不匹配
信号量不是互斥锁替代品。用 std::semaphore 做“N 路并发控制”，再套一层 std::mutex 保护共享数据，是常见组合；但顺序错了会死锁或失效。
典型错误：先 lock mutex，再 acquire semaphore —— 这会让 mutex 持有时间变长，抵消了信号量的并发收益；更糟的是，如果 acquire 阻塞，mutex 就一直占着，其他线程全卡住。
- 正确顺序：先
sem.acquire()，再mtx.lock()（如果真需要细粒度互斥） - 多数时候，你根本不需要 mutex：信号量本身已保证至多 N 个线程进临界区，共享资源若只读或自带原子性（如无锁队列），连 mutex 都可省
- 别把 semaphore 当作“高级 mutex”来用，它的语义是资源配额，不是临界区排他
编译和链接时 std::semaphore 不可用的几个硬条件
即使写了 #include <semaphore></semaphore>，也常遇到 “‘semaphore’ is not a member of ‘std’” 或链接失败。这不是代码问题，是环境没达标。
- C++ 标准必须设为
c++20（Clang/GCC 用-std=c++20，MSVC 用/std:c++20） - libstdc++ 需 GCC 11+，libc++ 需 LLVM 12+，MSVC 需 VS 2019 16.11+（早期预览版不完整）
- Linux 下还要确保 glibc 版本 ≥ 2.34（否则
sem_open等底层不可用），旧系统只能退到 pthread_semaphore 或自实现
最易被忽略的一点：CMake 项目里，set(CMAKE_CXX_STANDARD 20) 不等于启用 C++20 特性，还得加 set(CMAKE_CXX_STANDARD_REQUIRED ON)，否则编译器可能悄悄降级。
