不能直接用std::thread设优先级，需调用系统api：windows用setthreadpriority（依赖进程优先级类），linux用pthread_setschedparam（需指定调度策略并设置继承行为），二者语义、权限和效果均不同。
不能靠 std::thread 直接设优先级，必须调操作系统 API；Windows 用 SetThreadPriority，Linux 用 pthread_setschedparam；两者语义不同、权限要求不同、甚至“高优先级”的实际效果也不同。
Windows 下用 SetThreadPriority 设置线程优先级
它只调整线程相对于其所属进程基准的偏移量，不是绝对值。真正起作用的是进程的优先级类（SetPriorityClass），比如 HIGH_PRIORITY_CLASS 才能让 THREAD_PRIORITY_ABOVE_NORMAL 有明显效果。
-
GetCurrentThread()返回当前线程句柄，安全可靠；但std::thread::native_handle()返回的HANDLE需确保未被关闭、且有THREAD_SET_INFORMATION权限，否则调用SetThreadPriority失败 - 普通用户进程默认只能在
THREAD_PRIORITY_IDLE、THREAD_PRIORITY_NORMAL、THREAD_PRIORITY_HIGHEST范围内调整；想设THREAD_PRIORITY_TIME_CRITICAL必须先提权或用REALTIME_PRIORITY_CLASS（后者极危险，会抢占系统线程） - 常见错误：在线程启动后才去获取句柄并设优先级——因调度延迟，可能已执行完关键段；建议在线程函数入口第一行就调
SetThreadPriority(GetCurrentThread(), ...)
Linux 下用 pthread_setschedparam 设置调度参数
Linux 没有“线程优先级”这个概念，只有“调度策略 + 参数”。SCHED_OTHER（默认）下 sched_priority 被忽略，真正可调的是 nice 值（-20 到 +19）；而 SCHED_FIFO/SCHED_RR 才支持数值化优先级，但需要 CAP_SYS_NICE 能力（通常需 root 或 sudo setcap cap_sys_nice+ep ./your_app）。
- 必须显式设置继承行为：
pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED)，否则新线程会直接继承父线程调度策略，你设的参数无效 -
sched_get_priority_max(SCHED_FIFO)才是合法最大值（通常是 99），硬写 100 会导致pthread_setschedparam返回EINVAL - 不要在主线程里用
SCHED_FIFO后不设超时或让出 CPU——它会一直跑满一个核，连Ctrl+C都可能失效
跨平台封装时最易踩的坑
别对 std::thread::native_handle() 做类型强转或裸用。C++ 标准不保证它的返回类型：Windows 是 HANDLE，Linux 是 pthread_t，macOS 可能又是别的东西。一旦你写 (HANDLE)t.native_handle()，代码就彻底失去可移植性。
- 正确做法是条件编译：用
#ifdef _WIN32/#ifdef __linux__分开实现，函数接口统一（如set_thread_priority(std::thread&, int)），内部各自调原生 API - 优先级数值不能直接映射：Windows 的
THREAD_PRIORITY_HIGHEST≠ Linux 的sched_priority = 99；前者影响的是相对调度权重，后者决定是否能抢占其他实时线程 - 别把优先级当性能银弹：设高了可能饿死其他线程，设低了又没效果；真正瓶颈常在锁竞争、内存带宽或 I/O，而非调度顺序
线程优先级不是开关，而是调度器眼中的“建议权重”；操作系统有权忽略它，尤其在资源充足或策略受限时。最稳妥的做法，是只在明确知道调度行为边界（比如嵌入式实时任务、音视频同步线程）时才动它，其余情况优先优化算法和数据结构。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
