errno在C++多线程中是线程安全的，现代POSIX系统（如Linux、macOS）和主流C++标准库将其实现为线程局部宏（如glibc中定义为(*__errno_location())），C++11标准也明确要求其具有线程局部存储期；但需立即读取，避免被同一线程内后续调用覆盖。
errno 在 C++ 多线程中确实是线程安全的
现代 POSIX 兼容系统（Linux、macOS）和主流 C++ 标准库（libstdc++、libc++）中，errno 不是传统意义上的全局变量，而是通过宏展开为线程局部访问：例如在 glibc 中定义为 (*__errno_location())，每次读写都指向当前线程私有的存储位置。C++11 标准也明确要求 errno 具有线程局部存储期（thread-local storage duration），所以你无需额外加锁或封装就能在多线程中直接使用。
但“线程安全”不等于“可随意延迟检查”
即便每个线程有自己的 errno，它仍极易被**同一线程内后续的函数调用覆盖**。常见错误是：在系统调用失败后没立刻读取 errno，中间穿插了其他库函数（如 printf、malloc、甚至 strerror 自身），导致拿到的是无关错误码。
- ✅ 正确做法：在判断函数返回值失败后，**立即**读取
errno，不要跨语句、不要跨函数调用 - ❌ 错误模式：
if (fd == -1) { log_error(); printf("err: %d", errno); }——log_error()或printf可能已改写errno - ⚠️ 注意：
perror和strerror(errno)内部会读取并使用errno，但它们本身也可能触发其他系统调用（如write），因此也不建议在它们之后再依赖errno值
Windows 与 MinGW 的兼容性差异
Windows 上的 MSVC 运行时通过 (*_errno()) 实现线程局部 errno，行为与 Linux 一致；但 MinGW-w64 默认启用 POSIX 兼容模式，同样安全。不过，如果你手动链接旧版 MinGW 或启用非 POSIX 模式，errno 可能退化为全局变量——此时多线程下会出错。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- ✅ 安全前提：确保编译时定义了
_POSIX_THREAD_SAFE_FUNCTIONS（通常由工具链自动处理） - ? 验证方式：运行时打印
sizeof(errno)没有意义，但可检查&errno != &((void(*)())0, errno)是否恒成立（实际应比较地址稳定性），更可靠的是查阅目标平台errno.h中的宏定义 - ? 提示：跨平台项目中，若需绝对可控，可立即将失败后的
errno保存到局部变量，如int saved_errno = errno;，后续只用该副本
真正容易被忽略的点：信号处理函数中的 errno
在自定义信号处理函数（如 sigaction 注册的 handler）中，errno 的行为是未定义的——即使主线程中安全，信号中断上下文可能破坏其线程局部状态。POSIX 明确指出：信号处理函数中不应依赖 errno 值，除非你确认所用系统对此做了特殊保证（glibc 从 2.29 起在部分 handler 中保留 errno，但不可移植）。
立即学习“C++免费学习笔记（深入）”；
- ? 切勿在 signal handler 中直接使用
errno判断错误原因 - ✅ 替代方案：在主循环中用
signalfd（Linux）或sigwaitinfo同步接收信号，并在安全上下文中检查错误 - ⚠️ 补充：
write等异步信号安全函数（async-signal-safe）允许在 handler 中调用，但它们**不设置errno**；若需记录错误，必须提前把errno保存到static __thread变量中（注意初始化和竞态）
