c++oding="utf-8" ?>
最直接的方式是在日志处调用 std::this_thread::get_id() 获取当前线程 ID，其返回 std::thread::id 类型对象，支持直接流式输出。
用 std::this_thread::get_id() 获取当前线程 ID
日志输出时想带上调用方的线程 ID，最直接的方式就是在打日志的地方调用 std::this_thread::get_id()。它返回一个 std::thread::id 类型的对象，可直接流式输出（operator 已重载），但注意：它不是整数，也不是指针，不同实现下可能打印为数字、十六进制地址或空字符串（取决于标准库实现和调试符号）。
常见错误是试图把它当 int 或 uintptr_t 强转——这不可靠，且在 macOS（libc++）和某些嵌入式 libstdc++ 上会失败。
- 推荐做法：直接拼接进日志字符串，例如
os - 如果需要可排序/比较的数值 ID，得用
std::hash<:thread::id>{}(std::this_thread::get_id())得到一个size_t，但注意哈希值不唯一，仅适合做散列键，不能用于跨进程识别线程 - Windows 下若需 Win32 线程句柄或真实 TID（如
GetCurrentThreadId()返回的 DWORD），必须显式调用平台 API，std::this_thread::get_id()不提供该映射
日志宏里自动注入线程 ID 的安全写法
手动每次写 std::this_thread::get_id() 容易遗漏，也破坏日志接口一致性。更稳妥的是封装成宏或内联函数，在日志入口处统一获取。
关键点在于：获取 ID 必须在日志格式化开始前完成，否则若日志函数异步投递（如写入队列再由后台线程刷盘），拿到的就是后台线程的 ID，而非调用方线程 ID。
- 同步日志（如直接写文件或
std::cerr）：宏中立即调用std::this_thread::get_id()是安全的 - 异步日志：必须在调用线程上下文中把
std::this_thread::get_id()结果作为字段拷贝进日志事件结构体，不能延迟到消费线程再取 - 避免在宏里调用可能抛异常的函数（虽然
get_id()不抛），以防干扰原有异常语义
std::thread::id 打印为空或乱码？检查标准库和流状态
有些环境下 std::cout 输出为空或不可读字符串，通常不是代码错，而是：
- libstdc++（GCC）默认输出格式是
{0x...}形式，但若std::thread对象未真正启动过（比如只声明了std::thread t;未t.join()或t.detach()），其id是thread::id()默认构造值，流输出为空 - libc++（Clang/macOS）对
thread::id的流输出依赖调试信息，若编译时没开-g或链接了 stripped 的 libc++，可能输出为0x0或空白 - 确保流对象（如
std::cerr）未处于failbit或badbit状态，否则输出会被静默丢弃
需要稳定整数 TID？用平台 API + 条件编译
如果日志系统要求线程 ID 是单调递增整数、或需与系统级工具（如 perf、strace）对齐，std::this_thread::get_id() 无法满足。此时必须走底层：
- Linux：调用
syscall(SYS_gettid)，返回pid_t，即内核级线程 ID（TID），类型稳定为整数 - macOS / iOS：用
pthread_threadid_np(nullptr, &tid)，tid是uint64_t - Windows：
GetCurrentThreadId()返回DWORD（即uint32_t） - 注意：这些值在跨平台日志中不能直接混用；若需统一表示，建议加前缀（如
"linux-tid:12345"）或单独字段存储
线程 ID 的“身份含义”取决于你用它做什么：调试时看归属用 std::this_thread::get_id() 足够；做性能归因或系统联动，就得切到平台原生 TID —— 这两者从来就不是一回事，别指望一个接口通吃。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
