uniqid生成的RequestID不够唯一，因其仅依赖微秒时间戳，高并发或容器化环境下易碰撞，且缺乏进程/线程/主机标识与加密随机性，不适用于分布式追踪。
uniqid 生成的 RequestID 为什么不够唯一？
uniqid 默认只基于微秒时间戳，同一毫秒内多次调用会返回相同值；在高并发或容器化环境中（如多进程、多线程、FPM worker 复用），uniqid() 单独使用极易碰撞。它不包含进程/线程/主机信息，也无加密随机性，不能直接用于分布式请求追踪。
加盐后仍需注意的三个关键点
加盐（即传入第二个参数 $more_entropy 或拼接字符串）能缓解但不彻底解决唯一性问题：
-
uniqid('', true)启用$more_entropy会附加一个基于/dev/urandom（Linux）或CryptGenRandom（Windows）的 5 字符随机串，但 PHP 7.1+ 已弃用该参数，且其熵值有限，不保证跨进程唯一 - 手动拼接盐（如
uniqid('req_'.getmypid(), true)）依赖getmypid()，但在 PHP-FPM 中所有 worker 共享主进程 PID，实际无效 - 若用
$_SERVER['REQUEST_TIME_FLOAT']或microtime(true)拼接，仍可能因浮点精度截断或时钟回拨导致重复
推荐组合：uniqid + random_bytes + base64_encode
兼顾性能、可读性与唯一性，适合大多数 Web 请求场景：
// 生成 8 字节随机 + 时间前缀，Base64 编码后去除非 URL 安全字符
$request_id = substr(str_replace(['+', '/', '='], '', base64_encode(random_bytes(8))), 0, 12)
. '_' . substr(uniqid('', false), -6);
说明：
立即学习“PHP免费学习笔记（深入）”；
-
random_bytes(8)提供密码学安全随机字节，PHP 7+ 原生支持，不依赖外部熵源 -
base64_encode后替换+///=是为了适配 URL 和日志字段（避免转义或截断） - 拼接
uniqid(..., false)尾部 6 位，提供时间上下文，便于排序和粗略定位时间范围 - 总长控制在 18 字符内，兼容多数数据库
VARCHAR(32)字段，也易读
别忽略请求生命周期中的覆盖风险
RequestID 不是生成完就万事大吉——常见疏漏：
- 在 CLI 脚本或队列任务中复用 Web 请求的 RequestID，导致日志混杂；应统一通过
$_SERVER['REQUEST_ID']或全局常量注入，而非硬编码生成逻辑 - 使用
ob_start()或中间件多次初始化 RequestID，造成同一次请求出现多个 ID；建议在入口文件（如public/index.php）最开始处生成并存入$GLOBALS或静态属性 - 未将 RequestID 注入日志上下文（如 Monolog 的
Processor），导致错误堆栈里看不到关联 ID；需显式调用Logger::withContext(['request_id' => $id])或等效机制
真正难的不是生成一串字符，而是在整个请求链路中确保它被一致传递、不被覆盖、不被截断——尤其是跨子请求、cURL 调用或消息队列投递时，得靠 header 或 payload 显式透传，uniqid 本身管不了这些。
