mod_unique_id模块默认未启用，需通过httpd -M确认并手动启用；其生成的24字符Base64唯一ID需配合RequestHeader或LogFormat使用，且仅在完整请求处理流程中生成。
mod_unique_id 模块是否已启用
Apache 默认不启用 mod_unique_id，直接在配置里写 UniqueIDHeader 会报错：「Invalid command 'UniqueIDHeader'」。必须先确认模块加载状态。
执行 httpd -M | grep unique（Linux/macOS）或 apache2ctl -M | grep unique；Windows 下查 httpd.exe -M 输出。没看到 unique_id_module (shared) 就得手动启用：
- Debian/Ubuntu：运行
a2enmod unique_id，再systemctl reload apache2 - RHEL/CentOS：取消
LoadModule unique_id_module modules/mod_unique_id.so前的注释，再systemctl reload httpd - 源码安装：确保编译时含
--enable-unique-id，否则需重编译
如何把 ID 注入请求头或日志
mod_unique_id 本身不输出任何内容，它只在每个请求生命周期内生成一个 24 字符 Base64 ID（如 WvXaYz1bC2dE3fG4hI5jK6lM），后续要靠其他模块消费。
常见用法是透传到后端或记录进日志：
- 加请求头给后端：在
VirtualHost或Directory块中写RequestHeader set X-Request-ID "%{UNIQUE_ID}e" - 写入 access log：在
LogFormat中用%{UNIQUE_ID}e，例如LogFormat "%h %l %u %t \"%r\" %>s %b \"%{UNIQUE_ID}e\"" unique - 注意：
%{UNIQUE_ID}e是环境变量名，e表示 environment，不是拼写错误
为什么有些请求没有 UNIQUE_ID
不是所有请求都会触发 mod_unique_id 生成 ID——它只在 Apache 的「request processing phase」中初始化，若请求被提前拦截（如被 mod_security 拒绝、SSL 握手失败、或命中 LocationMatch 且未进入主处理流程），ID 就不会产生。
典型现象：
- 返回 400/403/503 时，
%{UNIQUE_ID}e在日志里为空或显示为破折号（-） -
curl -I http://host/看不到X-Request-ID头，但完整 GET 请求有 - 静态文件由
mod_cache或磁盘缓存直接返回时，可能跳过 ID 生成阶段
这不是 bug，是 Apache 处理链的设计使然。如果需要全量 ID，得结合 mod_setenvif 或自定义日志条件做 fallback。
和其它唯一 ID 方案（如 mod_headers + expr）的区别
有人会用 mod_headers 配合 expr 生成随机字符串，比如 Header set X-Req-ID "expr=%{RANDOM}"，但这和 mod_unique_id 本质不同：
-
mod_unique_id的 ID 全局唯一、时间有序、无碰撞风险，基于服务器启动时间 + 进程 PID + 时间戳 + 随机熵，专为分布式追踪设计 -
RANDOM是每请求生成的伪随机数，长度短、无序、有碰撞概率，且不能跨 Apache 子进程保持一致性 - 性能上，
mod_unique_id是 C 实现、零分配、无锁，比expr解析快一个数量级 - 如果你用 OpenTelemetry 或 Jaeger 做链路追踪，
UNIQUE_ID可直接作为 trace ID 使用，而自建方案需额外对齐格式
真正要注意的是：ID 生成发生在请求解析早期，但 header 注入或日志写入在后期——中间若发生重写（如 RewriteRule）或子请求（subrequest），UNIQUE_ID 不会变，这点和某些中间件自动生成的 request ID 不同。
