Linux下线程命名需用pthread_setname_np，限16字节且须在线程内调用；GDB需手动触发info thread查看；Windows用SetThreadDescription，无长度限制；跨平台应条件编译且仅调试构建启用。
Linux 下用 pthread_setname_np 设置线程名
Linux 原生不支持标准 C++ 的线程命名，得靠 glibc 提供的非标准扩展 pthread_setname_np。它只能设最多 16 字节（含结尾 \0）的名称，超长会被截断——这点极易被忽略，导致你在调试器里只看到前 15 个字符加省略号。
实操时注意：必须在目标线程内部调用，不能由其他线程代劳；且需链接 -lpthread（虽然多数现代编译器默认链接，但显式加上更稳妥）。
- 在
std::thread启动函数开头立即调用：pthread_setname_np(pthread_self(), "worker-1");
- 若用
std::this_thread::get_id()获取 ID，无法直接转成pthread_t，必须从std::thread对象用native_handle()提取：std::thread t([]{ pthread_setname_np(pthread_self(), "io-handler"); }); - 调用失败会返回非零值（如
ERANGE表示名字太长），建议简单检查：if (pthread_setname_np(pthread_self(), name) != 0) { /* 日志或忽略 */ }
GDB 中如何查看线程名
线程名不会自动显示在 info threads 列表里——GDB 默认只显示 LWP ID 和状态。你得手动触发读取：
- 先用
info threads确认线程编号（比如2），再执行：thread 2<br>info thread
这时 GDB 才会尝试从内核读取该线程的 name 字段并显示在括号中，形如：Thread 2 (LWP 12345) "worker-1" 0x00007f... in ... - 如果括号里仍是空的或显示
"(No name)"，说明pthread_setname_np没生效（常见原因：名字超长、调用时机错、没在目标线程内调用） - GDB 9.2+ 支持
set print thread-events on，新线程创建/退出时会打印带名字的日志，但前提是名字已成功设置
Windows 下用 SetThreadDescription 替代
Windows 10 1607+ 提供了官方 API SetThreadDescription，接受 PCWSTR（宽字符串），长度无硬性限制（实际受系统资源约束），比 Linux 的 16 字节宽松得多。
立即学习“C++免费学习笔记（深入）”；
- 必须包含
#include <processthreadsapi.h>，且最低目标平台设为_WIN32_WINNT_WIN10 - 调用方式简洁：
SetThreadDescription(GetCurrentThread(), L"main-loop");
- Visual Studio 调试器原生支持该字段：线程窗口（
Ctrl+D, K）和“调试 > 窗口 > 线程”中会直接显示描述文本，无需额外命令 - 旧版 Windows（如 Win7）调用会失败，返回
E_NOTFOUND，应做容错处理，而非崩溃
跨平台封装要注意的坑
别试图用宏一层层包裹出“统一接口”——Linux 和 Windows 的语义、生命周期、错误处理完全不同。最稳妥的做法是：按平台条件编译，且只在调试构建中启用。
- Release 构建中跳过命名逻辑（避免无谓系统调用开销）：
#ifdef DEBUG<br> #ifdef __linux__<br> pthread_setname_np(...);<br> #elif defined(_WIN32)<br> SetThreadDescription(...);<br> #endif<br>#endif
- 不要依赖线程名做业务逻辑（比如根据名字决定调度策略），它纯属调试辅助信息，内核不保证持久性或唯一性
- 某些容器环境（如 Docker + seccomp）可能禁用
prctl(PR_SET_NAME)底层调用，导致pthread_setname_np静默失败——此时 GDB 里永远看不到名字，得查容器安全策略
线程名不是魔法标签，它依赖底层 OS 支持、调试器版本、甚至容器配置；真正容易被忽略的是：名字必须在线程启动后、首次系统调用前设置，否则可能被内核忽略。
