uniqid() 默认不唯一，仅基于微秒时间戳，高并发易碰撞；须设 more_entropy=true（PHP 7.1+ 强制）并加前缀，否则应改用 random_bytes() 等强随机方案。
uniqid() 生成的 ID 并不真正唯一
直接说结论：uniqid() 默认不加参数时，只基于微秒时间戳生成字符串，同一毫秒内多次调用大概率碰撞——尤其在高并发或循环中。它不是 UUID，也不带随机性，本质是“时间戳+可选前缀”的拼接。
常见错误现象：uniqid() 在 for 循环里连跑 10 次，结果返回一堆重复值（比如 "66a8b1f4c2a1e" 出现 5 次）；或者在 CLI 脚本里快速重跑，ID 看似不同但实际只差几个字符，毫无区分度。
- 必须加
more_entropy=true参数才启用系统随机数（如/dev/urandom），否则纯靠时间戳，精度受限于系统时钟分辨率 - PHP 7.1+ 中，
more_entropy=false已被标记为 deprecated，未来会移除，别再依赖它 - 前缀（第一个参数）建议传入有意义的标识，比如模块名或用户 ID 片段，避免不同服务生成相同 ID 后意外冲突
替代方案：什么时候该用 random_bytes() + bin2hex()
如果你需要强唯一性、抗碰撞、且不依赖时间（比如生成 API token、临时密钥），uniqid() 就不该出现在代码里。它的设计目标只是“短生命周期、低并发下的轻量 ID”，不是安全凭证。
使用场景：生成上传文件名、日志追踪号、缓存键前缀等对安全性无要求但需一定区分度的场合；若涉及权限、会话、支付单号等，必须换方案。
-
bin2hex(random_bytes(16))生成 32 字符十六进制字符串，碰撞概率极低（远低于uniqid('', true)） -
base64_encode(random_bytes(12))更短（约 16 字符），但含+、/和=，注意 URL 安全性，可用strtr()替换 - PHP 8.2+ 可用
random_int()配合自定义字符集，但复杂度上升，一般没必要
uniqid() 的兼容性陷阱：Windows 下 more_entropy 基本失效
在 Windows 系统上，即使你写了 uniqid('', true)，PHP 实际无法读取高质量熵源（/dev/urandom 不可用），回退到低质量伪随机，导致输出长度固定为 13 字符（而非 23），且重复风险显著升高。
错误现象：本地 WAMP/XAMPP 开发时 ID 看似正常，上线 Linux 服务器后反而出现更多重复；或者 CI 测试在 GitHub Actions（Linux）通过，但在本地 Windows Git Bash 失败。
- 不要在跨平台项目中假设
more_entropy=true总是生效 - 检查运行环境：
var_dump(function_exists('random_bytes'));比依赖uniqid()更可靠 - 如果必须用
uniqid()，至少加上唯一上下文前缀，例如uniqid($_SERVER['REQUEST_ID'] ?? '', true)
性能对比：uniqid() 快，但快≠合适
uniqid() 几乎无开销，比 random_bytes() 快一个数量级——但它省下的那几微秒，往往换来更难调试的并发问题。
真实瓶颈通常不在 ID 生成，而在后续的数据库写入、网络 IO 或锁竞争。用错函数带来的修复成本（查日志、改表结构、补数据）远超这点性能收益。
- QPS uniqid('', true) 问题不大
- API 网关、订单创建、秒杀入口等场景，强制用
random_bytes()，别省这点 CPU - 如果真卡在 ID 生成，说明你可能在循环里反复调用它，先检查逻辑是否该批量生成或用自增 ID + 盐值拼接
真正容易被忽略的是：很多人把 uniqid() 当作“PHP 自带 UUID”，却没意识到它既不符合 RFC 4122，也不保证分布式唯一。哪怕加了 more_entropy，它仍是时间优先、随机兜底的设计——这个前提没理清，后面所有优化都是徒劳。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
