uniqid() 经常重复是因为仅基于微秒时间戳、无随机熵，高并发或同微秒调用时极易冲突；它本质是快速生成近似唯一标识，非真正唯一。
uniqid() 生成的ID为什么经常重复？
uniqid() 默认只基于微秒时间戳生成字符串，不带随机熵，在高并发或同一微秒内多次调用时极易重复。比如在循环中快速调用、或在多进程/多线程 Web 请求中（如 PHP-FPM 多 worker 场景），uniqid() 返回值可能完全一样。
它本质不是为“唯一性”设计的，而是为“快速生成近似唯一标识”服务的——名字叫 uniqid，但行为上更像 microtime(true) 的字符串封装。
- 不加参数时长度仅 13 位（如
"67abc123"），纯时间基，无随机性 - 传
true作为第二个参数会附加 5 位随机字节，但该随机源来自getrandmax()，在旧 PHP 版本中可能只是线性同余，不可靠 - PHP 7.1+ 虽改用
rand()，但仍非密码学安全，且未解决毫秒级并发冲突
uuid扩展生成的UUID v4是否真唯一？
启用 ext-uuid（需编译安装）后，uuid_create(UUID_TYPE_RANDOM) 生成的是标准 UUID v4，理论上碰撞概率极低（约 2^122 分之一），但实际使用前必须确认两点：
- 扩展是否真的加载：
extension_loaded('uuid')必须返回true，否则调用直接报Fatal error: Uncaught Error: Call to undefined function uuid_create() - 系统熵池是否充足：Linux 下依赖
/dev/urandom，容器环境（如 Alpine）若未挂载或权限受限，uuid_create()可能阻塞或失败 - v4 UUID 是 36 字符（含 4 个短横线），若业务要求短 ID 或纯字母数字，需额外
str_replace('-', '', $uuid)处理
不用扩展也能安全生成唯一ID的组合方案
当无法装扩展、又不能接受 uniqid() 风险时，推荐用 random_bytes() + 时间戳 + 进程/请求标识拼接，兼顾可读性与唯一性：
立即学习“PHP免费学习笔记（深入）”；
function safe_id($len = 16) {
$time = bin2hex(substr((string)microtime(true), -6)); // 截取微秒后6位（去点号）
$rand = bin2hex(random_bytes(5)); // 10字符随机
$pid = getmypid() ?: 0;
return substr(sha1($time . $rand . $pid . $_SERVER['REQUEST_TIME_FLOAT'] ?? 0), 0, $len);
}
关键点：
-
random_bytes()是 PHP 7+ 原生加密安全随机函数，比mt_rand()可靠得多 - 混入
getmypid()和请求时间戳，有效隔离不同进程/请求上下文 - 用
sha1()哈希而非直接拼接，避免暴露原始熵源，也便于控制输出长度 - 不要用
md5()替代 —— 虽快但已不推荐用于新场景；也不要截取random_bytes()原始二进制，易含不可见字符
数据库主键冲突时，别只靠应用层重试
即使 ID 生成逻辑看似可靠，插入数据库仍可能因网络延迟、事务隔离、或分布式节点时钟漂移导致唯一索引冲突（SQLSTATE[23000]: Integrity constraint violation）。这时光靠“生成失败就再试一次”容易陷入死循环或放大延迟。
- 应用层最多重试 2–3 次，且每次间隔应指数退避（如 1ms → 2ms → 4ms）
- 更稳妥的做法是：让数据库承担最终唯一性保障，例如 MySQL 中用
INSERT ... ON DUPLICATE KEY UPDATE或 PostgreSQL 的INSERT ... ON CONFLICT DO NOTHING - 如果 ID 用于分库分表路由，务必确保生成逻辑在所有服务节点上行为一致（比如都用 NTP 同步时间、禁用本地时钟回拨处理）
真正难的不是“怎么生成一个看起来唯一的字符串”，而是“在分布式、高并发、时钟不稳、熵源受限的现实里，让这个字符串在业务全链路中不撞车”。很多坑藏在容器启动顺序、PHP 进程复用、甚至 $_SERVER 变量是否被代理清空这些细节里。
