POSIX XBD 基础定义与术语

• 掌握 character classes 与 locale 分类的关系
• 理解 LC_CTYPE 与 LC_COLLATE 各自职责及优先级
• 理解 setlocale 与工作区选区的机制

POSIX 规定 locale 是一个区域化环境集合，由若干分类（LC_CTYPE、LC_COLLATE、LC_MESSAGES、LC_MONETARY、LC_NUMERIC、LC_TIME）组成，每个分类独立控制字符分类、排序、消息、货币、数字和时间格式。字符类（character classes）如 [:alpha:]、[:digit:] 是这些分类定义中使用的抽象字符集合，由 LC_CTYPE 定义的单字节映射与字符分类决定其成员。LC_CTYPE 负责字符分类与转换（如 isalpha、toupper），而 LC_COLLATE 负责字符串排序规则（如 strcoll、collation 权重）。优先级方面，LC_ALL 会覆盖所有其他 LC_* 分类，而单独设置的 LC_* 覆盖对应的默认项；当 setlocale 时 LC_ALL 优先级最高，其次是个别 LC_* 变量，最后是程序默认的 C locale。实际应用中 locale 对象是"分区"的，LC_CTYPE 与 LC_COLLATE 可独立切换，互不覆盖。

优先级链的要点是 LC_ALL 具有最高优先级，而 LC_* 各分类彼此独立、可单独设置。开发者常误以为 LC_CTYPE 决定一切，实际上排序（LC_COLLATE）与字符分类（LC_CTYPE）由不同分类控制，可分别配置。理解这一点对调试"排序异常"和"字符识别异常"至关重要。

• 掌握 feature test macros 的语义
• 理解 _POSIX_VERSION 与 _XOPEN_VERSION 的取值
• 掌握缺失时的条件编译兼容写法

选项的可用性在编译期通过 <unistd.h> 中的 feature test macro（如 _POSIX_VERSION、_XOPEN_VERSION、_POSIX_C_SOURCE）判断。代码在 #include <unistd.h> 之前定义 _POSIX_C_SOURCE=200809L 或 _XOPEN_SOURCE=700 即可请求对应接口；编译期可用 #ifdef _POSIX_VERSION 与 #if _POSIX_VERSION >= 200809L 判断运行系统是否支持某版本。缺失时（如无法定义宏）采用条件编译的兼容写法：用 #if defined(_POSIX_VERSION) 包裹 POSIX 专有代码，用 #else 提供回退实现（如使用标准 C 或非 POSIX 等价函数）。同时可用 sysconf() 在运行期查询选项是否激活，编译期与运行期判断互补。

关键点在于 feature test macro 必须在任何系统头文件之前定义，否则 glibc 等库会按默认值展开，导致占用宏不被识别。兼容写法本质是"先探测、再条件编译、最后回退"的多级策略，既保证在支持环境下启用高性能接口，又不破坏旧系统编译。

• 理解 GNU gettext 的 gettext/dgettext 机制
• 掌握两种机制的编译期与运行期差异
• 理解国际化与本地化的取舍

catgets 是传统 POSIX 消息目录机制，使用 catopen 打开目录、catgets 按消息集编号（set number）和消息编号取字符串，消息存储在二进制 .cat 文件中，需要专门的编译器（gencat）生成，编号维护繁琐且不具备可读性。GNU gettext 则基于文本格式的 .po/.pot 文件，通过 msgfmt 编译为 .mo 二进制，用 gettext("原文") 或 dgettext(catalog, "原文") 以原文作为键查找翻译，翻译文件可读可维护，支持复数形式、上下文等高级特性。gettext 的优势在于以源字符串为键、无需维护编号、工具链成熟、社区支持广泛；catgets 的优势在于严格 POSIX 标准化、无额外依赖，但可维护性差。现代项目普遍采用 gettext，catgets 仅用于严格的 POSIX 合规环境。

两者本质差异是"以编号为键"与"以字符串为键"。gettext 的可用性更高，且自动把源字符串作为 msgid，翻译缺失时回退原文，这一"回退到原文"的机制正是应用的最小惊讶原则。catgets 编号错位会导致取到错误消息，gettext 则天然避免。

• 理解 mbrtowc 与 wcrtomb 的签名与语义
• 理解重入状态 mbstate_t 的用途
• 理解状态机在 EOF 与 reset 时的行为

mbrtowc 将单个 multibyte 字符转换为宽字符，wcrtomb 做反向转换。两者都接受一个 mbstate_t *ps 参数作为转换状态，用于处理状态依赖的可变长编码（如 UTF-8 的续字节、GB18030 的四字节序列）。当 ps 为 NULL 时使用内部静态状态，不可重入；跨线程或需要对多个独立流编码时须传入各自独立的 mbstate_t 对象。转换函数在收到不完整但合法的多字节序列时返回 (size_t)-2，表示"输入不足，需要更多字节"，应用需保留状态继续读取；遇到非法序列返回 (size_t)-1 并置 errno=EILSEQ。使用 mbrtowc 的返回值可判断转换进度，使用 mbsinit 判断状态是否处于初始状态。状态机本质是"累计字节并维护中间状态直到完整字符或出错"。

状态机管理的关键是区分"不完整输入"（返回 -2，合法、可继续）与"非法序列"（返回 -1，出错）。传入独立的 mbstate_t 才能保证多流/多线程转换的正确性，NULL 全局状态在并发下会互相污染。现代编码 UTF-8 无状态，但 POSIX 必须兼容状态依赖编码，故状态机不可或缺。

• 理解不同引擎（回溯式 vs 线性式）的差异
• 掌握静态分析与动态检测方法
• 掌握超时与资源限制等防护手段

ReDoS 源于回溯式正则引擎（PCRE、Python re、Java）在匹配嵌套量词与选择分支时的时间复杂度随输入指数或多项式增长，恶意输入可令 CPU 耗尽。线性式引擎（RE2、基于 NFA/DFA 无回溯）则保证 O(n) 匹配时间。检测方法包括：静态分析（如检测嵌套量词 (a+)+、(a|a)* 等危险模式，工具如 safe-regex、rxxr2）；动态模糊测试（用随机与边界输入触发超时）；单元测试断言匹配时间在阈值内。防护手段包括：对正则匹配设置超时（PCRE 的 match_limit、RE2 天然安全）、拒绝嵌套量词、使用无回溯引擎、限制输入长度。跨语言语义差异（如命名分组的语法、\d 的含义、Unicode 处理）还可能导致"同一正则在不同引擎行为不同"的漏洞，需统一基线测试。

ReDoS 的本质是回溯引擎的最坏情况复杂度不随输入线性增长。检测的核心是找出"可变长重复内部再套可变长重复"的量子化模式，而防护则是在引擎层限制回溯步数或改用线性引擎。跨语言时需注意引擎语义差异，避免"在 A 语言安全、在 B 语言爆炸"。

• 理解 statvfs 中 fsblkcnt_t/fsfilcnt_t 的语义
• 理解不同位宽下的溢出风险
• 掌握 LFS 与 64 位类型的使用

blkcnt_t 用于 stat 的 st_blocks（占用块数）、fsblkcnt_t 用于文件系统总块数与空闲块数、fsfilcnt_t 用于文件总数。在 32 位平台或未启用 LFS 时这些类型可能为 32 位有符号，当文件系统块数或文件数超过 2^31 时发生有符号溢出，导致 st_blocks 出现负值、statvfs 报告错误容量。规避方法：启用 _FILE_OFFSET_BITS=64 让 glibc 使用 64 位 off_t 与相关类型；使用 _LARGEFILE64_SOURCE 下的 stat64/statvfs64 接口；仅依赖 64 位平台或显式断言类型位宽。诊断时用 sizeof(blkcnt_t) 与 sizeof(off_t) 检查位宽，并检查 _POSIX_V7_LF_BIG 等能力宏。

溢出风险的本质是"文件系统容量超过了类型位宽"。现代大数据文件系统在 32 位类型下必然溢出。LFS 通过 _FILE_OFFSET_BITS=64 将 off_t 及相关类型提升为 64 位，是标准解法。用 sizeof 检测位宽是避免隐式溢出的关键。

• 理解不同 libc 实现的内存布局差异
• 理解二进制兼容性（ABI）问题的成因
• 掌握正确的使用方式（pthread_attr_init 等）

pthread_attr_t 是 POSIX 定义的"不透明类型"（opaque type），标准只规定其语义，不规定内部布局。glibc 与 musl 为实现不同功能（如栈分配策略、调度参数存储）安排了不同的字段顺序、大小与填充，致使 sizeof(pthread_attr_t) 和内存布局不同。若把 glibc 编译的含 pthread_attr_t 的二进制与 musl 的动态库混用，或跨 libc 序列化/传递该结构，就会因布局不一致而读到错误数据或越界。此外 pthread_attr_t 的 ABI 在不同 glibc 版本间也可能变化。正确做法是始终通过 pthread_attr_init/get/set 等函数访问，绝不直接访问内部字段、绝不假设其大小或布局、绝不跨 libc 传递该结构体。

不透明类型的核心是"面向接口而非面向实现"。直接访问或硬编码 pthread_attr_t 大小会导致在不同 libc 上行为未定义。这也是所有 POSIX 类型需要遵循"只通过函数操作"原则的典型例子。

• 理解它如何限制 glibc 扩展接口
• 理解对嵌入式交叉编译的影响
• 掌握 feature test macro 与 STRICT_ANSI 的配合

__STRICT_ANSI__ 是 GCC/Clang 在严格 ANSI 模式下（如 -std=c99、-std=c11，不带 GNU 扩展）自动定义的宏。当它被定义时，libc 头文件会抑制 POSIX/GNU 扩展接口的声明，只暴露标准 C 接口，从而保证代码严格符合 C 标准。在嵌入式交叉编译中，若用 -std=c99 等严格模式编译，会无法使用 strdup、fileno、getline 等 POSIX 扩展，导致编译错误；反之若用 -std=gnu99 则不会定义该宏，扩展接口可用。影响：严格模式增加可移植性但牺牲便利性，需用 _POSIX_C_SOURCE/_DEFAULT_SOURCE 显式请求扩展，或改用 gnu 模式。嵌入式工具链常默认 gnu 模式以提供更多接口，但若追求严格标准符合需要显式控制。

STRICT_ANSI 本质是"编译器向 libc 声明的标准模式信号"。它不自动启用 POSIX 接口，而是抑制非标准接口。嵌入式交叉编译因为要面向多平台与受限 libc，需精确控制这一宏，否则会在"严格合规"与"可用接口"之间失衡。

• 理解 fork/exec/wait/exit 的语义与组合
• 理解异步信号安全（async-signal-safe）函数集合
• 理解信号处理器中可安全调用的函数限制

fork 创建子进程（复制父进程内存与资源，但仅创建线程的调用者），exec 用新程序替换当前映像，wait 等待子进程终止并回收资源，exit 终止进程并刷新 stdio 缓冲。四个族构成进程生命周期管理。异步信号安全（async-signal-safe）指该函数可在信号处理器中安全调用，因为信号处理器可能打断任意代码执行点，若调用非安全函数会造成重入或死锁。POSIX 规定 sigaction、sigemptyset 等信号管理函数本身是 async-signal-safe 的，因为它们只操作信号集合或注册回调，不依赖全局锁（如 malloc 的锁），因而可在信号处理器中安全调用。而 printf、malloc 等因持有内部锁或使用非重入状态，属于非安全函数，不能在信号处理器中直接调用。

async-signal-safe 的核心是"信号打断点不可预测"。fork/exec/wait/exit 与 sigaction 的关联在于：exec 后信号处置会重置为默认（被捕获的信号），而 fork 后保留，这些继承语义需要信号函数配合。理解安全的函数子集是正确编写信号处理代码的前提。

• 理解信号量进程内与跨进程使用
• 理解 sem_timedwait 的超时语义
• 理解 robust semaphore 的用途与条件

sem_init 创建未命名信号量，可指定 pshared 参数（0 表示进程内线程间共享，非 0 表示可跨进程共享但需放在共享内存中）；sem_open 创建/打开命名信号量，天然用于跨进程，具有内核持久性。sem_timedwait 在超时时间内等待信号量，超时返回 -1 且 errno=ETIMEDOUT。robust semaphore（PTHREAD_MUTEX_ROBUST 的同步）用于解决"持有信号量或互斥锁的进程崩溃"导致的其他等待者永久饿死问题：通过检测 owner 死亡自动恢复并返回 EOWNERDEAD，使后继者能恢复共享状态。robust 属性是随锁/信号量对象存储的，归属在被创建的进程/共享内存中，跨进程共享时必须由所有参与者同意使用 robust 语义。

sem_init 与 sem_open 的关键差异是"未命名 vs 命名、进程内 vs 跨进程"。robust 机制解决的是持锁进程崩溃后的死锁恢复，是健壮性设计的关键。错误的 pshared 设置会导致跨进程共享失效。

• 理解 fork+exec 的开销与风险
• 理解 posix_spawn 在无 MMU 环境的价值
• 理解 posix_spawn 的文件操作与属性设置

posix_spawn 将"创建子进程并替换为另一程序"合并为一个原子操作，由系统实现内部完成，避免了 fork 复制整个父进程地址空间的开销，尤其适合无 MMU（如嵌入式 RTOS）或内存受限环境。它通过 posix_spawn_file_actions_t 与 posix_spawnattr_t 指定继承/重定向的文件描述符与进程属性（调度、信号掩码等），比手写 fork+exec 更简洁且不易出错。功能差异：fork+exec 可以执行更复杂的中间逻辑（如 fork 后设置环境、修改资源限制），而 posix_spawn 的定制能力受限，某些高级操作（如修改父进程私有状态）仍需 fork+exec。在 Linux 上 posix_spawn 常由 fork+exec 或 clone 实现，但语义上提供可移植、高效的便携接口。

posix_spawn 的价值在于"可移植 + 低成本 + 原子性"。它消除 fork 的复制开销与二义性，是嵌入式与高性能场景的更优选择。但需要更复杂的定制时仍要 fork+exec。

• 理解 SIGEV_SIGNAL 与 SIGEV_THREAD 的差异
• 理解回调线程与线程取消的交互
• 理解定时器清理与取消点的行为

timer_create 可指定过期通知方式：SIGEV_SIGNAL（发送信号）或 SIGEV_THREAD（在专用线程中调用回调函数）。SIGEV_THREAD 时内核/glibc 为每个定时器创建一个新线程执行回调，该线程在回调结束后自动退出，且回调线程默认的信号掩码、取消状态遵循规范。在 Linux 上，回调线程会运行在独立的线程中，定时器过期连续触发时可能创建多个线程。线程取消交互：回调线程若未设置 PTHREAD_CANCEL_DISABLE，则可能被取消点（如 pthread_join、pthread_mutex_lock 等）取消；若回调中使用 pthread_cond_wait 等带取消点的函数，取消可能中途终止回调。设计上应使用 pthread_cleanup_push 清理资源，或禁用取消以保证回调完整性。

SIGEV_THREAD 的回调线程生命周期与线程取消紧密相关：回调线程在完成后自动退出，但若被取消则需清理资源。正确处理需结合 pthread_cleanup_push/pop 与取消状态控制，避免回调中途被取消导致资源泄漏。

• 理解跨设备（cross-device）的限制
• 理解 EXDEV 与 EBUSY 等错误码
• 理解 rename 的原子性

link 创建硬链接，要求源与目标在同一文件系统（跨设备返回 EXDEV，因为硬链接基于同一 inode 与挂载点）。unlink 删除一个目录项，若链接数归零则释放文件，若文件正被打开则延迟删除。rename 重命名文件，若目标与源在同一文件系统内是原子的；跨设备时返回 EXDEV，且 POSIX 规定 rename 跨设备时可能失败并应回退到 copy+unlink。remove 是统一接口，文件用 unlink，目录用 rmdir，返回相应错误。EBUSY 可能出现在删除正在使用的资源（如挂载点目录）时。语义要点：rename 的同文件系统原子性是关键保证，跨设备则需自行实现复制+删除。

跨设备限制的本质是"inode 隶属于单一文件系统"。rename 的原子性只对同文件系统成立，跨设备必须回退。返回码语义（EXDEV、EBUSY、ENOTEMPTY）是判断失败原因的关键。

• 理解 POSIX 与 Linux 具体实现的区别
• 掌握字段兼容性诊断方法
• 理解类型差异（f_bsize、f_frsize 等）

statvfs/fstatvfs 是 POSIX 标准接口，字段包括 f_bsize（block size）、f_frsize（fragment size）、f_blocks（总块数）、f_bfree、f_bavail、f_files、f_ffree、f_favail、f_fsid、f_flag、f_namemax。Linux 的 statfs 是系统调用，字段为 f_type、f_bsize、f_blocks、f_bfree、f_bavail、f_files、f_ffree、f_fsid、f_namelen、f_frsize。两者 f_bsize 语义相似但 statfs 的 f_bsize 可能是文件系统块大小，而 statvfs 的 f_bsize 是"用于计算的基础块大小"，f_frsize 才是实际最小块。诊断方法：使用 _FILE_OFFSET_BITS=64 保证字段为 64 位；比较两结构字段名与类型；用 #ifdef HAVE_STATVFS 做条件编译；在目标系统上打印 sizeof 与字段值验证。类型差异（f_bsize 是否为 unsigned long 等）在不同架构上可能不同。

兼容性诊断的核心是"以 POSIX 标准接口为准，避免依赖 Linux 私有字段"。statvfs 的 f_frsize 与 f_bsize 的区分常被忽略，导致容量计算错误。跨平台时应统一用 statvfs 并做类型与字段探测。

• 理解锁的继承与释放语义
• 理解 NFS 上的锁行为差异
• 理解 fcntl 锁与进程/文件描述符的关系

fcntl 记录锁（POSIX 锁）基于文件中的字节区间（offset/length），可对文件部分区域加锁，粒度更细；锁与进程绑定（同一进程的多个 fd 共用同一把锁，关闭任一 fd 会释放该进程的全部锁），且不随 fork 继承。flock 是 BSD 风格的整文件锁，粒度是整个文件，锁与打开的文件描述（open file description）绑定，可由 fork 后的父子共享，对同一 inode 的多次 open 表现为同一把锁。NFS 语义：fcntl 锁在 NFS 上通过 NLM 协议实现，可能受 NFS 版本、锁管理配置影响，跨地域一致性差；flock 在 NFS 上常被映射为 POSIX 锁或不可靠。单进程内 truncate/close 对 fcntl 锁的影响需注意（close 任一 fd 释放所有锁）。

核心差异是"字节区间 vs 整文件"与"进程绑定 vs 文件描述绑定"。fcntl 锁粒度更细但 close 语义复杂（关闭任一 fd 释放全部锁），flock 更简单但限定整文件。NFS 上两者都需谨慎，因为分布式锁一致性依赖锁管理协议。

• 理解 NFS 锁协议（NLM）的工作机制
• 理解分布式锁的一致性问题
• 理解锁失效与恢复的局限

fcntl 记录锁在 NFS 上通过 NLM（Network Lock Manager）协议实现，锁由 NFS 服务器维护。局限性包括：1) 锁管理依赖网络往返，客户端或服务器崩溃时锁可能失效或得不到及时清理；2) 锁的粒度与字节区间在网络传输中存在开销与一致性风险；3) NFS 版本差异（v3/v4）对锁的支持不同，v4 用 NFSv4 锁协议，行为与 NLM 不同；4) 锁与名文件名/句柄绑定，硬链接或重命名可能使锁语义混乱；5) 分布式锁存在"锁丢失"与"锁占用者退出后锁未释放"的窗口，客户端需轮询或依赖租约。对一致性要求高的场景，应使用带租约的分布式锁（如 ZooKeeper、etcd）而非 NFS 文件锁。

分布式锁的局限源于"锁状态与网络、服务器状态耦合"。NFS 文件锁缺乏强租约与自动恢复，跨地域不一致。因此关键业务应避免依赖 NFS 文件锁，改用分布式锁服务。

• 理解符号链接跟随的默认规则
• 理解路径解析的循环检测
• 理解 O_NOFOLLOW 等标志的影响

POSIX 路径解析默认跟随符号链接：在解析路径时，若某个路径成分是符号链接，则按其目标内容继续解析，直到到达最终目标。跟随规则：对中间成分默认跟随，对最终成分由具体操作决定（如 open 跟随，lstat 不跟随）。ELOOP 在两种情况下产生：1) 路径解析中符号链接级联超过系统上限 SYMLOOP_MAX（Linux 上为 40），即链接层级过深；2) 符号链接形成循环（如 a -> b，b -> a），导致无限跟随。此时解析终止并返回 ELOOP。O_NOFOLLOW 标志使 open 在最终成分为符号链接时不跟随并返回 ELOOP，用于防止链接指向意外目标。

ELOOP 是"链接链过长或成环"的统一错误。跟随规则与 O_NOFOLLOW 共同构成路径解析的安全控制。理解循环检测与级联上限是解析路径安全的关键。

• 理解 . 与 .. 段在解析中的处理
• 理解 trailing slash 对符号链接的影响
• 理解目录解析的规则

路径末尾的斜杠（trailing slash）表示该路径必须解析为目录。若路径以斜杠结尾且最后成分为符号链接，则会跟随该链接到其目标目录（若目标不是目录则报错 ENOTDIR）。点段（.）表示当前目录，解析时被忽略；点段（..）表示父目录，解析时会回退一级。trailing slash 对符号链接的影响：即使链接目标本身是文件，若路径带末尾斜杠，则要求目标是目录。对中间成分的符号链接，跟随其目标继续解析；对最终成分的符号链接，若带 trailing slash 则跟随其目标目录。

trailing slash 强制目录语义，是解析路径时容易忽略的边界。. 与 .. 的纯文本处理在符号链接场景下可能产生歧义（如 a/../b 中 a 是链接时，POSIX 解析引擎按内核逐段处理，会对中间链接做跟随）。理解这些规则有助于避免路径解析偏差。

• 理解符号链接指向绝对路径的处理
• 理解链接深度限制
• 理解级联跟随的终止条件

绝对路径以 / 开头，从根目录开始解析；相对路径从当前工作目录（cwd）开始。当路径中遇到符号链接时，若链接目标以 / 开头（绝对路径），则解析基准切换到根目录，继续按绝对路径解析；若链接目标为相对路径，则相对该链接所在目录（而非 cwd）继续解析。解析深度限制：内核会追踪符号链接跟随级数，超过 SYMLOOP_MAX（Linux 40）即返回 ELOOP，防止无限循环与恶意的深层链接导致内核栈耗尽。每次跟随（即使目标为绝对路径）都与前一级的深度累计，直到达到根或完成。

符号链接目标为绝对路径时"重置基准到根"是关键，解释了为何链接能跨目录跳转。深度限制保护内核资源，是路径解析的硬约束。应用构造路径时需注意链接带来的基准变化。

• 理解 O_NOFOLLOW 的语义
• 理解两者对符号链接跟随的影响
• 理解 O_PATH 与后续操作（readlink、*at）

O_NOFOLLOW 使 open 在最终路径成分为符号链接时不跟随它，并返回 ELOOP；用于防止打开意外的链接目标（如安全场景）。O_PATH 是 Linux 扩展，打开一个文件描述符但不真正打开文件内容，仅用于获取路径引用，可用于后续 fstat、readlink、*at 系列操作；O_PATH 打开不会跟随符号链接，且不触发文件系统读取。两者结合：O_NOFOLLOW|O_PATH 常用于对符号链接本身执行操作（如 readlinkat 前先安全打开）。O_PATH 标志不保证文件可读写，只用于路径操作。O_NOFOLLOW 只影响最终成分，中间成分的链接仍跟随。

O_NOFOLLOW 控制"最终成分是否跟随链接"，O_PATH 提供"不真正打开文件的路径句柄"。两者常配合用于安全地处理符号链接本身，避免 TOCTOU 与意外的链接跟随。

• 理解符号链接与点段的处理
• 理解失败时的错误码（ENOENT、EACCES、ELOOP）
• 理解 realpath 的缓冲区与 NULL 参数

realpath() 将输入路径解析为绝对标准化路径：解析所有符号链接、消除 . 与 .. 段、合并重复斜杠，并返回以 / 开头的规范路径。它内部逐段解析，跟随符号链接，用内核路径解析逻辑得到最终规范路径。失败语义：路径不存在返回 NULL 并置 errno=ENOENT；无权访问返回 EACCES；符号链接循环或级联过深返回 ELOOP；路径过长返回 ENAMETOOLONG。返回的规范路径必须是真实存在的路径（最后一层必须存在）。传入 NULL 作为 resolved_path 时，POSIX 允许实现分配缓冲区（glibc 会 malloc），但需注意可移植性；传入 buffer 时需保证 PATH_MAX 大小。

realpath 的"规范化"= 消除链接与点段 + 得到绝对路径。因为需解析链接，其要求路径存在，失败错误码反映具体原因。这是安全路径处理的常用工具，但需注意缓冲区管理与 POSIX 可移植性。

• 理解 Process/Thread/Realtime Signal/Thread Cancellation 的定义
• 理解 XBD 与 SUSv4 的关系
• 理解术语定义对实现的约束

XBD（Base Definitions）是 POSIX/SUSv4 的第一卷，提供术语与通用定义，包括 Process、Thread、Realtime Signal、Thread Cancellation 等核心概念。Process 定义为"执行上下文，含地址空间、线程与资源"；Thread 定义为"进程内可独立调度的执行单元"；Realtime Signal 定义为"带排队、优先级与附加数据的信号"；Thread Cancellation 定义为"请求线程终止并执行清理的机制"。SUSv4 由 XBD、XSH（系统接口）、XCU（命令）、XRAT（原理说明）四卷组成，XBD 是基础卷，XSH 等引用其术语。差异主要在组织方式：XBD 统一术语，SUSv4 分工后强调"单一 UNIX 规范"与 IEEE 1003.1 的合并。

XBD 是定义的"字典"，SUSv4 是 XBD+XSH+XCU+XRAT 的完整规范。术语定义对实现构成硬约束（如 Realtime Signal 必须排队、Thread Cancellation 必须支持取消点）。理解 XBD 是理解 POSIX 语义的基础。

• 理解 normative 与 informative 的区别
• 理解 must/should/may 的规范性强度
• 理解一致性测试依赖的条款

POSIX 标准区分 normative（规范性）与 informative（信息性）内容。normative 章节包含必须遵守的规范（must/shall 条款），是实现合规性的依据；informative 章节（如原理说明、示例）提供背景与解释，不构成硬性要求。must/shall 表示强制要求，实现必须满足；should 表示推荐但非强制；may 表示允许，实现可选择。一致性测试套件（VSX 用于 XPG，CTS 用于 POSIX 一致性）主要验证 must/shall 条款，因为只有这些是可测试的、必须满足的；should/may 条款通常不进入强制测试，或作为可选测试。实现一致性声明（ICS）需列出支持与可选的选项。

must/should/may 是规范性的"强度等级"。一致性测试只能验证 must 级条款，因为 should/may 留给实现选择。理解这一区分能帮助判断"哪些行为是跨实现保证的"。

• 理解 Async-Signal-Safety 的定义
• 理解 Torn Read 的定义
• 理解这些术语对实现的约束

Race Condition（竞态条件）指多个执行单元并发访问共享数据且结果依赖执行顺序的状态，XBD 将其定义为"MSG 对共享对象的访问竞争，结果不确定"。Async-Signal-Safety（异步信号安全）指函数保证可在信号处理器中安全调用，即不依赖会导致重入/死锁的全局状态。Torn Read（撕裂读）指在多字节对象访问中，因并发写或非原子访问导致读到部分旧值部分新值的混合状态。这些术语对实现的硬约束：代码必须避免竞态（用同步原语）；信号处理器只能调用 async-signal-safe 函数；对多字节共享数据必须使用原子或对齐访问避免撕裂读。这些约束决定了并发与信号处理代码的正确性边界。

三术语是并发正确性的基础：竞态定义"谁来竞争"，异步信号安全定义"信号处理器能调什么"，撕裂读定义"底层访问的原子性"。它们共同规定代码必须使用同步原语、原子访问与受限的信号处理函数。

• 理解接口数量保持在约 1200 个
• 理解卷次拆分（XBD/XSH/XCU）
• 理解 2017 主要是技术勘误合并

POSIX 1003.1-2008 首次将 IEEE 1003.1 与 Open Group 的 SUSv4 合并为单一规范，分为 XBD（基础定义）、XSH（系统接口）、XCU（命令）、XRAT（原理说明）等卷。1003.1-2017 是对 2008 的修订，主要合并了 2008 之后发布的技术勘误（Technical Corrigenda），而非大规模扩充新接口，因此接口数量保持约 1200 个左右。演进背景：2008 版统一了 POSIX 与 UNIX 标准，2017 版在保持稳定性的前提下修正错误、澄清语义，避免破坏已有实现。这让实现者与开发者有稳定的接口基线。

2017 是"勘误合并"而非"新增功能"，这是接口数量稳定的原因。理解这一演进有助于判断"哪些接口是稳定的、哪些是新增的"。卷次拆分是为了清晰组织定义、接口、命令与原理。

• 理解 Priority Inheritance 的语义
• 理解 glibc 与 musl 的实现差异
• 理解内核支持与用户态实现

Robust Mutex（健壮互斥锁）用于处理持锁线程崩溃导致其他线程永久阻塞的问题，通过记录锁持有者，在持有者死亡时返回 EOWNERDEAD 让后继者恢复。Priority Inheritance（优先级继承）用于解决优先级反转：持有低优先级锁的线程会临时继承阻塞在其上的高优先级线程的优先级，避免高优先级任务被无限阻塞。实现差异：glibc 依赖内核的 futex 支持健壮互斥与优先级继承（通过 pthread_mutexattr_setrobust 与 PTHREAD_PRIO_INHERIT 协议，内核用 rt_mutex 实现优先级继承）；musl 也支持这些语义，但实现更轻量、更依赖统一的 futex 抽象，对某些协议的支持细节与 glibc 不同（如 musl 对 robust 支持较完整，但优先级继承的支持可能更有限或依赖内核）。两者都与内核 futex 交互，但用户态封装与调度细节不同。

两者都依赖内核 futex 与 rt_mutex。glibc 功能更全面、与内核配合更紧密；musl 更精简，可能在部分协议（如优先级继承）上支持有限。差异影响跨 libc 的线程行为与调度表现。

• 理解 Configuration 与 Option Group
• 理解 Subprofiling 概念
• 理解 autoconf 的探测方法

SUSv4 中，Configuration 描述系统能力（通过 sysconf 变量与 Pathconf 查询），Option Group 定义可选功能集合（如 MCS、DEBUG、XSI），实现可声明支持与否。Subprofiling 指将系统选项进一步细分，允许实现只支持部分子集。这些组合通过 <unistd.h> 的宏与 sysconf() 运行期查询暴露。autoconf 的 AC_CHECK_FUNC 在编译期检查某函数是否存在，与这些选项关联：AC_CHECK_FUNC 探测函数符号，但对于"符号存在但选项未激活"的情况，还需用 AC_CHECK_HEADERS 与运行期 sysconf 结合。配置探测组合是"编译期宏 + 运行期 sysconf + 可达性检查"。

配置/选项/子配置是"能力声明"的层次。autoconf 的 AC_CHECK_FUNC 只是符号探测，不能替代运行期选项查询。完整探测需结合编译期与运行期，确保接口真正可用。

• 理解 ICS/ISR 的一致性声明
• 理解测试套件如何验证选项
• 理解选项声明与实测的对应

POSIX 1003.1 的选项在某些场景（如 X/Open 的 XOM/XDS 等）用 ASN.1 描述系统对象与选项编码，用于结构化表示一致性信息。实现一致性声明（ICS，Implementation Conformance Statement）是厂商声明其支持哪些选项与接口的文档，ISR（Implementation Standard Report）记录实现与标准的差异。测试套件（如 VSX、posix_openpt 系列）据 ICS 选测：读取 ICS 确定应测试的选项子集，然后对每个选项执行对应测试用例，验证声明与实际行为一致。若选项声明支持但测试失败，则判定不合规；若声明不支持则跳过对应测试。ASN.1 编码用于规范化选项参数的表示，便于协议层解析。

ICS 是"声明"，测试套件是"验证"。测试按 ICS 选择用例，确保声明与实际一致。ASN.1 是选项编码的规范化手段，主要服务于特定接口（如 XOM）。理解两者的对应关系是开展一致性测试的前提。

• 理解 shaded interface（阴影/灰显接口）
• 理解实现责任的定义
• 理解标注的作用

在 POSIX/UNIX 一致性文档中，marked-up interface（加标记接口）通过标注（如 SYNOPSIS 中的标记）指出接口属于哪个标准版本或选项组，标注表明该接口可用时必须满足的条件；shaded interface（灰显/阴影接口）则表示该接口在特定选项下是可选或已废弃的，实现是否支持取决于选项。实现责任差异：加标记接口指明接口所属的一致性集合，实现若声明该集合则必须实现；灰显接口表示接口可选，实现可在声明不支持时不必提供，但若提供需符合语义。灰显通常用于"可选选项"或"受选项限制"的接口，帮助实现明确哪些是必需、哪些是可选。

两类标注都用于区分"必需 vs 可选"。marked-up 强调接口归属的集合，决定实现责任；shaded 强调可选性，实现可自由选择。正确理解标注能判断实现是否必须提供某接口。

• 理解 LC_ALL 覆盖其他 LC_* 的优先级
• 理解环境变量与 setlocale 的关系
• 理解 locale 选择的顺序

POSIX locale 优先级链：LC_ALL 最高，覆盖所有其他 LC_* 分类；其次各独立 LC_（LC_CTYPE、LC_COLLATE 等）；最后是 LANG 作为默认值。setlocale(category, locale) 设置指定分类的 locale：若 locale 为 ""，则按环境变量（LC_ALL、相应 LC_、LANG，最后 C）选择；若为 "C" 或 "POSIX" 则使用默认 C locale；若为 NULL 则查询当前分类的 locale 名称。setlocale 影响进程全局状态，多线程下需注意（POSIX 要求 setlocale 是全局的，可用 locale 的每线程版本如 uselocale 扩展）。实现时 LC_ALL 优先解析，若 LC_ALL 未设置则逐级回退到 LC_* 与 LANG。

优先级链是"LC_ALL > LC_* > LANG > C"。setlocale 的 "" 参数触发环境变量解析，是应用初始化的标准方式。实现的关键是正确按优先级回退，并注意全局状态的多线程影响。

• 理解 grep/sed/awk 的默认正则类型
• 理解 POSIX 正则与 Perl 兼容的差异
• 掌握不同工具间的正则取舍

POSIX 定义两种正则：BRE（基本）与 ERE（扩展）。BRE 中 ( ) { } + ? 需转义成 \( \) \{ \} \+ \? 才表示分组/量词；ERE 中这些元字符直接生效。grep 默认用 BRE（grep -E 切换 ERE），sed 默认 BRE，awk 默认 ERE。POSIX::regex 是 POSIX 标准接口（regcomp/regexec），支持 BRE/ERE，但不支持 Perl 的环视、非贪婪、命名分组等。Perl 兼容模式（PCRE）功能强大但语义不同。取舍：需要严格 POSIX 语义与跨平台一致时用 POSIX::regex；需要复杂匹配（环视、反向引用更多特性）时用 PCRE，但需注意性能与 ReDoS 风险。跨工具调用时需注意审查正则与工具默认的方言。

BRE/ERE 的转义差异是移植性陷阱。grep/sed/awk 默认方言不同，需显式指定。POSIX 与 PCRE 在功能与语义上的取舍决定选型，通常以"可移植优先 vs 功能优先"为准。

• 理解 ( ) 与 { } 在两种方言中的含义
• 理解移植性风险
• 掌握跨工具/跨系统的一致写法

BRE（基本正则）中，(、)、{、}、+、? 是字面字符，要表示分组或量词必须转义为 \(、\)、\{、\}、\+、\?。ERE（扩展正则）中这些元字符直接有效，无需转义。差异导致同一正则表达式在 BRE 与 ERE 下含义不同：如在 BRE 中 a(b) 匹配字面 "a(b)"，而在 ERE 中 a(b) 匹配 "ab" 的一组。移植性影响：脚本中若未指定方言，同一正则在不同工具（grep/sed/awk）下行为不同；跨平台（不同 grep 实现）也可能有差异。建议明确指定方言（如 grep -E），避免依赖默认；对可移植正则，避免使用方言特有转义，采用两种方言都安全的写法。

转义差异是 BRE/ERE 的本质区别。移植性风险源于"默认方言"与"转义规则"的隐性差异。显式指定方言并测试是保证可移植性的关键。

• 理解 Unicode 类别（L、N 等）
• 理解两者的等价关系
• 理解差异（合成字符、字素等）

POSIX 字符类基于 locale 定义，如 [:alpha:] 表示字母、[:alnum:] 表示字母或数字、[:digit:] 表示数字。在 Unicode 环境下，POSIX 字符类通常映射到 Unicode 类别：[:alpha:] 对应 Unicode 字母类别（Lu、Ll、Lt、Lm、Lo），[:alnum:] 对应字母或数字（L 或 Nd），[:digit:] 对应 Nd（十进制数字）。差异：1) POSIX 字符类受 locale 影响，不同 locale 下成员可能不同（如某些 locale 的 [:alpha:] 可能不含某些重音字母）；2) Unicode 类别更细粒度，可区分大小写、数字、标点等；3) 合成字符（combining characters）与字素簇在两者中的处理不同，POSIX 字符类按码点，Unicode 按类别还可能涉及规范化。等价是"语义近似"而非"完全一致"，具体取决于 locale 与 Unicode 版本。

等价是"按语义映射"，但 locale 敏感性使两者不完全一致。差异集中在 locale 依赖、细粒度类别与合成字符处理。跨平台使用 Unicode 时需明确用 Unicode 类别还是 POSIX 字符类。

• 理解宽度差异（32/64 位）
• 理解 ABI 兼容性
• 理解 LFS 与类型稳定性

POSIX 系统类型如 pid_t、size_t、ssize_t、off_t、mode_t 在不同平台上有不同宽度（如 size_t 在 32 位为 32 位、64 位平台为 64 位；off_t 受 LFS 影响）。宽度稳定性与 ABI 兼容性通过以下方式保证：1) 类型由编译器与 libc 联合定义，遵循 ABI 规范（如 System V ABI）；2) 关键类型（off_t、rlim_t）通过 _FILE_OFFSET_BITS=64 统一为 64 位，保证大文件支持；3) 结构体布局（如 struct stat）由 ABI 约定，跨 libc 版本保持稳定；4) 使用 sizeof 与类型别名而非硬编码宽度，避免依赖假设。ABI 兼容意味着同一二进制的传参/返回类型布局一致，否则会破坏二进制兼容。pid_t 通常为 32 位有符号，off_t 在 64 位平台为 64 位。

宽度稳定性依赖 ABI 规范与 LFS 宏。ABI 兼容要求类型布局在库版本间稳定。开发者应避免硬编码类型宽度，使用类型别名与 sizeof，并通过 LFS 宏统一 off_t 位宽。

• 理解 clock_t 与 clockid_t 的差异
• 理解 CLOCK_REALTIME 与 CLOCK_MONOTONIC
• 理解单调时钟与墙上时钟

clock_t 是时间计数类型（如 clock() 返回的 CPU 时间单位），clockid_t 是时钟标识符类型（如 CLOCK_REALTIME、CLOCK_MONOTONIC）。取值范围因实现而异：CLOCK_REALTIME 是墙上时钟（wall clock），反映系统真实时间，可被 NTP 调整、用户手动设置，可能跳变或回拨；CLOCK_MONOTONIC 是单调时钟，从某个固定起点（如系统启动）递增，不受系统时间调整影响，但可能受挂起/休眠影响（部分实现 CLOCK_BOOTTIME 包含挂起时间）。用途：测量时间间隔用 CLOCK_MONOTONIC（避免跳变），显示时间或与外部对齐用 CLOCK_REALTIME。clockid_t 的取值与系统支持范围由 clock_getres 等查询。

核心差异是"墙上时钟可调 vs 单调时钟不可回拨"。测间隔用单调时钟，记录时间点用实时时钟。clock_t 与 clockid_t 是"计数类型"与"时钟标识"的区别，取值范围与时钟实现绑定。

• 理解 NFA 与 DFA 引擎
• 理解回溯与性能
• 理解最左最长匹配（leftmost-longest）

正则引擎分 NFA（非确定有限自动机）与 DFA（确定有限自动机）。NFA 引擎通常基于回溯实现，支持捕获组、反向引用等高级特性，但最坏情况可能指数退化（ReDoS）；DFA 引擎将 NFA 编译为 DFA，每次匹配 O(n) 线性，无回溯，但内存可能指数增长（状态爆炸），且不支持捕获组/反向引用。POSIX 标准要求 leftmost-longest 语义（最左最长匹配），即匹配最左位置且最长的子串。NFA 引擎通过回溯找最长匹配，DFA 引擎天然可计算最长匹配。性能影响：DFA 稳定线性但内存大，NFA 灵活但可能慢。glibc 的 regex 用混合引擎（NFA 为主，带 DFA 优化），POSIX 语义由 NFA 回溯实现。

NFA/DFA 的核心取舍是"功能 vs 性能/内存"。POSIX 的最长匹配语义对 NFA 的回溯有额外要求。理解引擎类型可判断 ReDoS 风险与捕获组支持。

• 理解 C/POSIX locale 的默认行为
• 理解云厂商镜像的语言环境
• 理解 locale 缺失对应用的影响

容器镜像（尤其是精简的 Alpine 等）常只安装 C/POSIX locale，或不安装完整 locale 数据。默认 locale 为 C/POSIX 时，字符分类、排序、消息等按 ASCII 处理，不支持 UTF-8（LC_CTYPE=C 时多字节字符按字节处理）。云厂商镜像（如 Ubuntu/Debian 官方镜像）通常提供 en_US.UTF-8 等 locale，但并未默认启用，需显式 locale-gen 或设置 LANG。差异影响：应用若依赖 UTF-8 字符分类或地域格式，在 C locale 下会出错（如正则处理非 ASCII、排序错误、日期格式错误）。容器中应显式设置 locale 并确保 locale 数据已安装，否则回退到 C locale 导致行为异常。最小镜像（scratch）甚至无 libc locale 数据。

容器默认 C/POSIX locale 是"最小的、ASCII 的"环境。云厂商镜像可能预装 locale 数据但未启用。应用需显式声明 locale 需求，否则遇到 UTF-8 处理异常。这解释了为何容器应用常需 ENV LANG=C.UTF-8。

• 理解回退策略
• 理解最小惊讶原则
• 理解 locale 缺失时的处理

setlocale 失败表示请求的 locale 不可用（数据缺失或编译环境下未安装）。POSIX 语义：setlocale(category, "") 若环境中指定 locale 不可用，实现可能回退到 C locale 或返回 NULL。最小惊讶原则：1) 应用应检查 setlocale 返回值，若失败则回退到 C locale（保证基本功能），并记录警告；2) 不要静默忽略，要提示用户 locale 不可用；3) 对关键功能（如字符串处理）在 C locale 上可能行为不同，需让开发者知晓；4) 提供显式 locale 配置方式，避免依赖环境。总之回退到 C locale 是可预测的兜底，但因为可能改变排序/编码行为，需配合日志与用户提示，实现"可预期且告知"的最小惊讶。

最小惊讶不是"努力用用户预期 locale"，而是"失败时回退到可预测的 C locale 并明示"。静默忽略或半途使用不完整 locale 都会造成更大惊讶。检查返回值并回退是正确做法。

• 理解 REG_NOSUB/REG_EXTENDED/REG_ICASE
• 理解跨平台兼容性
• 理解不同实现（glibc、POSIX）差异

regcomp 接受 flag：REG_EXTENDED（使用 ERE 而非 BRE）、REG_ICASE（忽略大小写）、REG_NOSUB（不报告子表达式位置，可提升性能）、REG_NEWLINE（处理换行相关语义）。兼容性矩阵：这些 flag 在 POSIX 标准中定义，glibc 与 BSD 等实现基本支持，但个别行为有差异：REG_NOSUB 在 glibc 中若同时需要捕获组可能被忽略；REG_ICASE 对 locale 的字符分类敏感；REG_NEWLINE 的换行处理语义在不同实现中可能不同。跨平台移植时需注意各 flag 的精确语义与性能影响，并通过文档确认实现差异。标准保证的是 flag 语义的大致一致，细节（如 ERE 的某些特性）因实现而异。

flag 语义在标准中定义，但实现细节（尤其 REG_NEWLINE、REG_IMAX 等非标准扩展）有差异。REG_NOSUB 提升性能但不能取子串。理解兼容性矩阵需区分标准 flag 与实现扩展。

• 理解回退实现的代价
• 理解 PCRE 与 RE2 的优势
• 理解业务选型

POSIX regex（regcomp/regexec）功能有限：不支持环视、非贪婪、命名分组、Unicode 属性等现代特性，且各实现差异大。不可用时回退实现（如手写解析器或简化匹配）代价高：代码量大、易出错、性能差、难以覆盖复杂规则。业务系统依赖 PCRE 或 RE2 的原因：PCRE 提供丰富功能（环视、反向引用、Unicode 支持）与 Perl 兼容，适合复杂匹配；RE2 提供线性时间匹配（无回溯、抗 ReDoS），适合高吞吐与不可信输入。选型：需要复杂语义用 PCRE，需要安全与性能用 RE2。两者都提供跨平台、功能完善的库，比 POSIX regex 更贴合业务需求。

POSIX regex 的功能与性能天花板，使业务系统改用 PCRE/RE2。回退实现代价高是因为要复刻复杂匹配语义。PCRE 强在功能、RE2 强在安全/性能，是业务选型的两极。

• 理解 sigset_t 与 sigaction 的结构
• 理解跨平台 ABI 兼容性测试
• 理解结构成员差异

sigset_t 是信号集合类型，Linux 与 BSD 的 sigaction 结构字段相似（sa_handler/sa_sigaction、sa_mask、sa_flags、sa_restorer）但布局与 ABI 可能不同：Linux 的 sigaction 有 sa_restorer（SA_RESTORER），BSD 布局不同；sigset_t 的大小与实现（Linux 内核 sigset_t 为 64 位，而 glibc 用户态 sigset_t 为 128 字节（1024 位）位图；BSD 用数组）不同。跨平台 ABI 兼容性测试方法：1) 用 sizeof/offsetof 验证结构大小与字段偏移；2) 用 sigaction 设置并读取信号处置，验证字段往返一致；3) 用 sigemptyset/sigaddset 操作并通过 sigismember 验证；4) 跨库（libc 版本）测试确保二进制兼容；5) 用 _Static_assert 检查关键字段偏移。关键在于通过 API 而非直接访问结构字段，避免 ABI 差异。

sigset_t/sigaction 的 ABI 差异体现在布局与扩展字段。测试应通过 API 往返读写并用 sizeof/offsetof 检查布局，避免直接访问字段。跨 libc/跨平台需验证 ABI 稳定性。

• 理解 _FILE_OFFSET_BITS=64
• 理解 off_t 与 rlim_t 的位宽
• 理解启用条件与影响

LFS（Large File Support）使程序能处理超过 2GB 的文件与 64 位偏移。在 glibc 中，通过定义 _FILE_OFFSET_BITS=64 使 off_t、rlim_t 及相关类型成为 64 位，并让 open/read/write/lseek 等使用 64 位偏移。启用条件：必须在任何系统头文件之前定义 _FILE_OFFSET_BITS=64（通常通过编译选项 -D_FILE_OFFSET_BITS=64 或源码顶部定义）。同时 _LARGEFILE64_SOURCE 提供独立的 off64_t 与同名 64 位函数（如 lseek64）。关系：_FILE_OFFSET_BITS=64 重定义 off_t 为 64 位，使现有代码透明支持大文件；_LARGEFILE64_SOURCE 提供显式的 64 位接口。rlim_t 在 64 位平台自然为 64 位，32 位平台需 LFS。未启用时 off_t 为 32 位，超过 2GB 会溢出。

_FILE_OFFSET_BITS=64 是"透明启用 LFS"的关键，需在包含头文件前定义。它让 off_t 及相关类型变 64 位，避免大文件溢出。_LARGEFILE64_SOURCE 提供显式 64 位 API。理解两者关系是正确处理大文件的前提。

• 理解三个 feature test macro
• 理解覆盖接口范围
• 理解宏的优先级

glibc 的 feature test macro 决定暴露哪些接口。_POSIX_C_SOURCE 请求 POSIX 接口，取值指定版本（如 200809L 对应 POSIX 2008）；_XOPEN_SOURCE 请求 X/Open 接口（如 700 对应 SUSv4），包含 _POSIX_C_SOURCE 的接口并扩展；_GNU_SOURCE 请求 glibc 的全部 GNU 扩展，包含 _POSIX_C_SOURCE 与 _XOPEN_SOURCE 的所有接口，并启用非标准扩展。生效层级：_XOPEN_SOURCE 隐含 _POSIX_C_SOURCE（更高版本），_GNU_SOURCE 隐含两者。默认（未定义任何宏且非严格模式）时 glibc 启用 _DEFAULT_SOURCE（包含 POSIX 与 BSD 扩展）。这些宏需在包含任何系统头文件前定义，越靠后使用的宏覆盖范围越大。同时定义多个时，以定义值启用对应集合。

层级关系是"POSIX ⊂ X/Open ⊂ GNU"。_GNU_SOURCE 覆盖最广，_POSIX_C_SOURCE 最窄。正确选择宏决定可用接口，需在头文件前定义，且按需求取最合适层级。

• 理解 feature macro 在两套头文件中的传播
• 理解宏冲突与污染
• 掌握控制传播的方法

MinGW/MSYS 在 Windows 上提供 POSIX 兼容层，但程序可能同时包含 POSIX 头文件（如 pthread.h）与 Windows SDK 头文件（如 windows.h）。feature macro 的传播问题：POSIX 宏（_POSIX_C_SOURCE 等）可能影响 Windows 头文件的编译（如 _WIN32 相关判断），Windows 宏（WIN32、UNICODE 等）也可能误传入 POSIX 代码。控制方法：1) 用 include 隔离，避免在同一头文件同时包含两套头文件；2) 用条件编译 #ifdef _WIN32 区分平台代码；3) 在包含 Windows 头文件前使用 #undef 清理可能冲突的 POSIX 宏；4) 用 MinGW 提供的 MSYS/POSIX 封装层，避免直接混合；5) 用命名空间或独立编译单元隔离。核心是避免宏跨头文件"泄漏"。

宏传播问题源于两套 SDK 的宏名冲突与干扰。控制手段是隔离、条件编译与清理宏。MinGW 的目标是兼容，但混合包含时需显式管理宏传播，否则产生编译错误或错误语义。

• 理解 POSIX 2008 接口
• 理解接口启用矩阵
• 理解 glibc 的版本判断

glibc 中用 _POSIX_C_SOURCE=200809L 启用 POSIX 2008（POSIX.1-2008）新增接口，如 strdup、strndup、getline、gmtime_r、localtime_r、pthread_mutex_timedlock 等。特征：glibc 在头文件中用 #if _POSIX_C_SOURCE >= 200809L 或 #ifdef _POSIX_C_SOURCE 结合版本判断启用特定接口。启用矩阵：不同接口的启用条件不同，有的只需 _POSIX_C_SOURCE 定义，有的需要特定版本值，有的还需要 _DEFAULT_SOURCE 或 _GNU_SOURCE。例如 POSIX 2008 的接口要求 _POSIX_C_SOURCE >= 200809L；而 _XOPEN_SOURCE=700 也隐式启用 POSIX 2008。glibc 版本对 POSIX 2008 的支持逐步完善，需搭配足够新的 glibc。开发者应显式设置 _POSIX_C_SOURCE=200809L 以启用标准接口。

OS 阈值是"接口是否暴露"的开关。_POSIX_C_SOURCE=200809L 启用 POSIX 2008 接口，不同接口次级条件不同。理解生效矩阵需结合 glibc 版本与宏阈值。

• 理解排队与优先级
• 理解 siginfo 附带数据
• 理解与 System V 信号的差异

POSIX 实时信号（SIGRTMIN 到 SIGRTMAX）支持排队、携带附加数据（siginfo_t 的 si_value）与优先级（数字越小优先级越高）。通过 sigqueue 发送带数据的信号，可排队多个相同信号。System V 信号（传统信号，如 SIGINT、SIGTERM）不排队，多个相同信号会合并为一次，且无法携带附加数据（除部分 siginfo）。实时信号用于更精确的信号通信，可传递整数/指针值。优先级：实时信号在队列中按数字调度，数字小的先处理。差异核心：实时信号有排队与数据，System V 信号合并且无数据。需注意实时信号数量有限（SIGRTMAX-SIGRTMIN+1）。

实时信号是 POSIX 对传统信号的重要增强：排队、数据、优先级。System V 信号是"合并、无数据"的简单信号。实时信号适合需要精确传递数据的场景，但数量有限。

• 理解底层系统调用与 stdio 封装
• 理解错误恢复差异
• 理解何时用哪种

open/read/write/close 是系统调用，无缓冲（直接读写内核），返回-1 表示错误并置 errno，适合精细控制与性能敏感场景（如阻塞/非阻塞、O_DIRECT）。fopen/fread/fwrite 是 stdio 库函数，带用户态缓冲（全缓冲/行缓冲/无缓冲），提升小数据量读写效率，但引入缓冲一致性（需 fflush/fsync）与错误处理差异（返回 EOF/0，用 ferror/feof 判断）。错误恢复：系统调用失败可立即重试（部分写需循环）；stdio 缓冲失败可能丢失未刷数据，需处理 fflush。选型：需要精确控制与高性能用系统调用，需要便携与简单用 stdio。

核心差异是"无缓冲系统调用 vs 带缓冲 stdio"。系统调用直连内核、错误即时；stdio 缓冲提升性能但增加一致性负担。错误恢复需区分 errno 与 ferror/feof。

• 理解 fdopendir 与 getdents
• 理解可移植性与性能
• 理解取舍

opendir/readdir/closedir 是 POSIX 标准目录遍历接口，可移植性好，readdir 返回 dirent 结构，但每次调用可能多次系统调用（getdents）。fdopendir 从已打开的 fd 创建目录流，便于与 openat 等结合避免 TOCTOU。getdents 是 Linux 底层系统调用，一次读取多个目录项，性能高但非 POSIX、不可移植。取舍：追求可移植性用 opendir/readdir；需要与 fd 操作结合（相对路径、避免竞态）用 fdopendir；需要极致性能且限定 Linux 用 getdents。readdir 是线程安全的（每流独立），但不可重入版本 readdir_r 已废弃。

取舍在"可移植性 vs 性能 vs 与 fd 结合"。opendir 可移植；fdopendir 支持 fd 语义；getdents 高性能但 Linux 专属。根据场景选择合适的目录遍历接口。

• 理解 Linux 上 aio 的实现问题
• 理解 io_uring 的优势
• 理解替代方案

POSIX aio（aio_read/aio_write/aio_suspend 等）在 Linux 上的 glibc 实现基于线程池，通过普通阻塞 I/O 回调模拟异步，或因内核 aio 支持有限而受限。glibc 的 aio 实现使用线程池，导致：1) 每次操作创建线程、开销大；2) 线程池容量受限，高并发下排队；3) 某些操作（如 aio_suspend）实现不完整。Man 页直接标注 aio 为 broken。io_uring 是 Linux 内核的现代异步 I/O 接口，通过提交队列（SQ）与完成队列（CQ）实现真正的异步、零系统调用多次提交、支持批量操作与零拷贝，性能远超 aio。替代方案：新代码优先用 io_uring；需要可移植 aio 时用 libaio 或基于线程池封装。

aio 在 Linux 的 broken 源于线程池模拟与内核支持有限。io_uring 提供真正的异步、批量、零拷贝，是现代替代。实时标识与选型切换需结合性能与可移植性。

• 理解规定的字符范围
• 理解跨平台可移植性
• 理解依赖其他字符的风险

POSIX 规定可移植文件名字符集（portable filename character set）为：A-Z、a-z、0-9、点（.）、下划线（_）、连字符（-）。POSIX 保证包含这些字符的文件名在所有系统上可移植。依赖其他字符（空格、中文、特殊符号、非 ASCII）虽在支持 UTF-8 的 Linux 上可用，但：1) 不同文件系统对字符集支持不同（如 Windows 上的保留字符、FAT 的编码限制）；2) 排序、规范化（Unicode NFC/NFD）在不同系统可能不同；3) 工具链（shell 脚本、Makefile）对特殊字符需转义，易出错；4) 跨平台同步（如移动存储）时可能失败。因此依赖可移植字符集之外的字符会损害可移植性。

可移植文件名字符集是"最低共同标准"。依赖字符集外字符在不同系统（字符编码、文件系统限制、工具转义）上存在多重风险。遵循该字符集是跨平台的最佳实践。

• 理解 IEEE 1003.1 与 ISO 9945 的关系
• 理解版权控制
• 理解实现者的参考需求

IEEE Std 1003.1 是 POSIX 的 IEEE 标准，ISO/IEC 9945 是相同的标准经 ISO/IEC 国际标准化的版本。两者内容基本一致，由 IEEE 与 Open Group 制定，再由 ISO/IEC JTC 1 采纳。协作模式：IEEE/Open Group 作为技术主导，ISO/IEC 作为国际标准化机构，通过联合协调确保文本一致。版权控制：标准文本受版权保护，但实现对标准的"合理引用"（如接口名、语义）可自由实施，标准组织的许可以及公开免费的在线访问（如 Open Group 的 pubs.opengroup.org）支持实现。实现者同时参考两份文件：IEEE 版提供权威技术细节，ISO 版提供国际标准地位与合规参考，两者在特定市场（政府采买、国际合规）各有价值。

IEEE 1003.1 与 ISO 9945 是同一标准的不同发布渠道。实现者为满足不同合规需求同时参考，且标准在线免费促进实现。版权允许实现使用接口名与语义。

• 理解 BSD、SVID、XPG、UNIX 的关系
• 理解 SUSv4 的统一
• 理解查阅方法

BSD（伯克利发行版）是 Unix 的衍生体系，SVID（System V Interface Definition）定义 System V 接口，XPG（X/Open Portability Guide）是 X/Open 的可移植性指南，UNIX 商标由 Open Group 认证。这些标准分别描述不同 Unix 体系。SUSv4（Single UNIX Specification v4）由 Open Group 与 IEEE 1003.1 统一，整合了 POSIX 与 X/Open 的要求，成为单一规范。兼容性矩阵：SUSv4 通过"选项组"（如 MCS、XSI、Realtime）标注各接口属于哪个体系，可用 unix -v 或查阅 Open Group 网站（pubs.opengroup.org）的接口标注。查阅方法：查看接口的 SYNOPSIS 标注（如 XSI、MCS 标记），或查阅 conformance 部分的能力宏。

各标准是不同 Unix 体系的历史规范，SUSv4 统一了它们。兼容性矩阵通过接口标注与选项组呈现。查阅 Open Group 官方文档是确认接口归属的标准方式。

• 理解 feature test macro 的生效时机
• 理解头文件包含顺序
• 理解 glibc 的默认处理

feature test macro 必须在包含任何系统头文件之前定义，因为头文件在预处理时根据这些宏决定暴露哪些接口声明；一旦头文件已处理，宏再定义也无效（声明已按旧状态生成）。glibc 的包含防护（如 GLIBC 检查）使同一头文件只处理一次，宏定义晚于首次包含不生效。未定义任何 feature test macro 时，glibc 默认启用 _DEFAULT_SOURCE（包含 POSIX 与 BSD 扩展，除 _GNU_SOURCE 的专属扩展），所以默认编译能使用大部分 POSIX 接口。但若用严格模式（-std=c11 等）定义了 STRICT_ANSI，则只暴露标准 C 接口。因此宏必须在头文件前定义，且默认行为取决于是否严格模式。

宏生效时机是"预处理包含决定接口"。头文件包含后宏失效。未定义时默认 _DEFAULT_SOURCE 暴露 POSIX 接口，但严格模式会限制。正确顺序是宏在前、头文件在后。

• 理解三个宏的语义
• 理解 glibc 2.19 的变更
• 理解迁移建议

在 glibc 2.19 之前，_BSD_SOURCE 启用 BSD 扩展、_SVID_SOURCE 启用 SVID 扩展，它们是独立的宏。glibc 2.19 引入 _DEFAULT_SOURCE 作为默认启用集合，取代了 _BSD_SOURCE 与 _SVID_SOURCE 的独立作用。具体时间线：glibc 2.19（2014）引入 _DEFAULT_SOURCE，当未定义任何 feature test macro 时启用它，且 _BSD_SOURCE 与 _SVID_SOURCE 被合并进 _DEFAULT_SOURCE 的语义；新代码应使用 _DEFAULT_SOURCE 而非 _BSD_SOURCE/_SVID_SOURCE。此后 _BSD_SOURCE/_SVID_SOURCE 被认为废弃（但为兼容仍保留），官方建议用 _DEFAULT_SOURCE 或 _GNU_SOURCE 替代。迁移：将 _BSD_SOURCE/_SVID_SOURCE 替换为 _DEFAULT_SOURCE（或按需 _GNU_SOURCE）。

glibc 2.19 把 BSD/SVID 扩展统一为 _DEFAULT_SOURCE。_BSD_SOURCE/_SVID_SOURCE 被弃用，新代码用 _DEFAULT_SOURCE。理解时间线便于迁移旧代码。

• 理解线程生命周期接口
• 理解取消状态与类型
• 理解取消与清理

pthread_create 创建线程，pthread_join 等待线程结束并回收，pthread_exit 终止当前线程，pthread_cancel 请求取消另一线程。取消机制：pthread_setcancelstate 设置取消状态（PTHREAD_CANCEL_ENABLE/DISABLE），pthread_setcanceltype 设置取消类型（PTHREAD_CANCEL_DEFERRED/ASYNCHRONOUS）。取消点（cancellation point）是线程可被取消的调用点（如 pthread_join、pthread_cond_wait、read、write 等）。默认：取消使能、延迟取消（deferred），即取消请求在到达取消点时生效。pthread_join 本身是取消点。关联：pthread_cancel 发出请求后，若线程处于 DISABLE 或非取消点，取消延迟；到达取消点或类型为 ASYNCHRONOUS 时立即取消。线程取消时执行 pthread_cleanup_push 注册的清理函数。pthread_exit 与取消都终止线程，但 pthread_exit 不触发取消路径。

取消状态/类型与取消点共同决定取消的时机。默认延迟取消使取消只在取消点发生，保证共享资源安全。pthread_join 是取消点，需注意与清理函数配合。

• 理解 AT_FDCWD 语义
• 理解相对路径基准
• 理解 TOCTOU 规避

*at() 系列（openat、fstatat、unlinkat、renameat 等）接受一个目录 fd 作为路径解析基准，若路径为相对路径则相对该 fd 解析，若为绝对路径则忽略 fd。AT_FDCWD 表示使用当前工作目录作为基准，行为与不带 at 的版本一致。优势：1) 避免 TOCTOU（time-of-check-to-time-of-use）——在检查与使用之间路径被替换导致竞态，通过持有目录 fd 并相对解析，避免依赖可变字符串路径；2) 支持对任意目录（不限于 cwd）做相对操作；3) 可用 O_PATH 打开目录 fd 后安全操作。典型场景：守护进程 chroot 后、避免任意路径替换、多线程 cwd 变化时。fstatat 的 AT_SYMLINK_NOFOLLOW 控制是否跟随链接。

*at() 用"目录 fd + 相对路径"替代"全局 cwd + 字符串路径"，消除 TOCTOU。AT_FDCWD 是"使用 cwd"的哨兵。这对安全文件访问至关重要。