linux下pthread_getname_np可读取线程名，但需先用pthread_setname_np设置，名称最长16字节（含'\0'），未设置则返回空或不可预测内容；windows需用getthreaddescription（宽字符，需localfree）；c++标准库无线程命名支持；跨平台须自行维护带锁的线程id与名称映射表。
Linux 下用 pthread_getname_np 获取线程名
Linux（glibc 2.12+）支持通过 pthread_getname_np 读取线程名，但要注意：这个名不是线程 ID，而是由 pthread_setname_np 显式设置的、最多 16 字节（含结尾 \0）的字符串。未设置过则返回空字符串或不可预测内容。
实操建议：
-
pthread_getname_np第二个参数是输出缓冲区，必须保证至少 16 字节；传入nullptr或长度不足会直接崩溃 - 主线程默认无名，子线程也默认无名——不调
pthread_setname_np就别指望有可用名称 - 跨平台代码中不要依赖此函数，它在 macOS / Windows 上完全不存在
char name[16];
int ret = pthread_getname_np(pthread_self(), name, sizeof(name));
if (ret == 0) {
printf("thread name: '%s'\n", name);
}
Windows 下用 GetThreadDescription（Win10 1607+）
Windows 10 build 14393 之后引入 GetThreadDescription，但它和 Linux 的行为不同：线程描述（description）是宽字符（WCHAR*），且需手动释放内存（用 LocalFree）。
常见错误现象：
- 误用
GetCurrentThread()句柄——它返回伪句柄，GetThreadDescription不接受，必须用OpenThread获取真实句柄（或直接传GetCurrentThreadId()对应的线程 ID 给调试器类工具） - 忘记检查返回值是否为
S_OK，直接解引用导致崩溃 - 把线程 ID 当作句柄传入，触发访问违规
更现实的做法是：只在调试/日志场景下用 SetThreadDescription + GetThreadDescription 配合使用，生产环境极少依赖。
C++20 std::jthread 和线程名无关
std::jthread 解决的是线程自动 join 和取消协作问题，标准库至今（C++23）**没有提供任何获取或设置线程名的接口**。别被名字误导——jthread 里的 j 是 joinable，不是 named。
如果你看到某些封装库（如 Boost.Thread 或第三方 logging 工具）提供了 get_name()，那一定是它们自己维护了映射表，底层仍靠平台 API 设置/读取，不是标准行为。
- 不要试图从
std::thread::id推出名称——它只是个不透明标识，可能只是数字或指针地址 - 想在线程启动时标记名称？只能在
std::thread构造后立刻调用平台 API 设置（如 Linux 调pthread_setname_np）
跨平台方案只能自己维护映射表
没有银弹。真正可靠的跨平台线程命名，只能在创建线程时主动记录：std::thread 对象、其 id、以及你赋予的字符串名三者绑定存入一个全局 std::unordered_map<:thread::id std::string></:thread::id>。
关键细节：
- 必须加锁（
std::mutex），因为多线程并发注册时会冲突 - 线程退出时要不要清理映射？要看需求——长期运行服务通常不清理，避免查找时锁竞争；短生命周期任务可考虑 RAII 清理，但注意析构时机可能晚于线程终止
- 别用
std::this_thread::get_id()作为 map key 后立刻在线程外查——ID 复用风险低但存在，尤其线程池场景
真正难的不是读写映射表，而是让所有线程初始化逻辑统一走这一套，而不是一部分用 pthread_setname_np、一部分靠 map、一部分干脆没名——混用会导致日志里一半是 “thread-7” 一半是 “(unnamed)”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
