PHP生成唯一ID，uniqid()够用吗？
不够用，尤其在高并发或需要跨服务唯一性时。uniqid()只基于微秒时间戳 + 可选前缀，不带随机性、无进程/机器隔离，同一毫秒内多次调用大概率重复。它适合单机低频场景（比如临时文件名），但不适合订单号、用户ID、API请求ID这类强唯一需求。
常见错误现象：uniqid()在循环里连用两次返回相同字符串；压测时出现重复ID写入数据库失败，报Integrity constraint violation。
- 如果只是生成临时缓存键，加个随机后缀就行：
uniqid('', true)（第二个参数启用熵值，但PHP 7.1+已弃用） - 若需更高可靠性，必须叠加随机或加密手段，比如
uniqid() . bin2hex(random_bytes(4)) - 注意：
uniqid()不依赖random_bytes()，所以即使random_bytes()不可用它也能运行——但这恰恰是隐患来源
要真正唯一，优先用random_bytes() + bin2hex()
这是PHP 7+最推荐的组合：密码学安全、无时钟依赖、跨进程/机器稳定。它不保证全局唯一（理论上极小概率碰撞），但实际中比uniqid()可靠几个数量级。
使用场景：生成API密钥、重置令牌、短期会话ID、数据库主键字符串（配合唯一索引）。
立即学习“PHP免费学习笔记（深入）”；
-
bin2hex(random_bytes(16))生成32位十六进制字符串（128 bit），足够日常使用 - 想更短可改用Base62编码（需自定义函数），但
bin2hex()兼容性最好、无字符集风险 - 别用
md5(microtime() . mt_rand())之类土法——mt_rand()非加密安全，且时间+随机仍可能被预测 - 性能影响几乎为零：
random_bytes()在Linux走/dev/urandom，Windows走CryptGenRandom，都是系统级快速接口
需要全局唯一且可排序？考虑snowflake或ULID
当业务要求ID既唯一、又含时间信息（便于排序/分片）、还支持多节点部署时，uniqid()和random_bytes()都不够。这时得上分布式ID方案。
PHP本身没内置snowflake，但可用成熟包如ramsey/uuid（推荐v4随机UUID）或轻量库ozankasikci/php-snowflake。
-
ramsey/uuid的Uuid::uuid4()本质是random_bytes(16)封装，带标准格式（含短横线），适合通用唯一标识 - 若要时间有序+紧凑，用ULID（如
ulid/ulid包）：Ulid::generate()生成26字符、按时间排序的字符串，比UUID短且无短横线 - 自己实现snowflake要小心时钟回拨问题——PHP-FPM子进程间时间不同步、NTP校正都可能导致ID重复或倒序
数据库自增ID vs PHP生成字符串ID，怎么选？
别默认“字符串更酷”。自增整型ID（AUTO_INCREMENT）在MySQL/PostgreSQL里有天然优势：索引效率高、存储省、JOIN快。PHP生成字符串ID只应在特定需求下引入。
容易踩的坑：用uniqid()或md5()生成ID后直接当主键，结果表体积暴涨、查询变慢、备份耗时翻倍。
- 如果业务需要隐藏增长规律（防爬序号）、支持分库分表、或对接外部系统要求字符串ID，再上PHP生成方案
- 生成后务必加
UNIQUE约束，且在插入失败时重试（不能忽略Duplicate entry错误） - 避免在事务里多次调用生成函数——万一回滚，ID已“泄露”，无法回收
真正麻烦的不是生成，是生成后的存储、索引、分片策略和错误重试逻辑。很多项目卡在这一步，不是函数不会用，是没想清楚ID在整个系统里的角色。
