直接用time()或uniqid()不行，因time()仅秒级精度致高并发重复，uniqid()依赖微秒+进程ID，易受虚拟机时钟回拨和PID复用影响；雪花算法通过结构化拼接时间戳、机器ID与序列号生成64位ID，兼顾唯一性、单调递增与水平扩展。
为什么直接用 time() 或 uniqid() 不行？
因为它们在分布式环境下会重复或缺乏时序性：time() 精度只有秒级，同一秒内多节点必然冲突；uniqid() 依赖微秒+进程ID，但微秒在虚拟机/容器中可能回拨，且进程ID范围小、易复用。雪花算法本质是把时间戳、机器ID、序列号打包成一个64位整数，既保证单调递增，又避免中心化单点。
snowflake_id() 函数怎么写才不丢精度？
PHP默认整型在32位系统上最大是231−1（约21亿），而雪花ID最高可达263−1，必须全程用 string 或 GMP 处理。但GMP依赖扩展，更稳妥的做法是用字符串拼接+bcadd()模拟位运算：
function snowflake_id($worker_id = 1, $datacenter_id = 1) {
static $last_timestamp = 0;
static $sequence = 0;
<pre class='brush:php;toolbar:false;'>$timestamp = (int)(microtime(true) * 1000);
if ($timestamp < $last_timestamp) {
throw new Exception('Clock moved backwards');
}
if ($timestamp == $last_timestamp) {
$sequence = ($sequence + 1) & 0xfff; // 12位，最多4095
if ($sequence === 0) {
$timestamp = wait_next_millis($last_timestamp);
}
} else {
$sequence = 0;
}
$last_timestamp = $timestamp;
$timestamp -= 1609459200000; // 自定义纪元（2021-01-01）
$id = sprintf('%s%s%s%s',
str_pad(decbin($timestamp), 41, '0', STR_PAD_LEFT),
str_pad(decbin($datacenter_id), 5, '0', STR_PAD_LEFT),
str_pad(decbin($worker_id), 5, '0', STR_PAD_LEFT),
str_pad(decbin($sequence), 12, '0', STR_PAD_LEFT)
);
return bindec($id); // PHP 7.4+ 可直接用，否则需用 bcadd/bcmul 模拟}
- 纪元时间必须统一，所有服务用同一个基准（如
1609459200000），不能用strtotime('2021-01-01')动态算 -
$worker_id和$datacenter_id必须全局唯一，建议从配置或环境变量注入，别硬编码 - 返回值用
bindec()是最简方案，但如果 ID > 9223372036854775807（PHPint最大值），必须返回string，否则高位截断
并发场景下 $sequence 为啥会溢出？
每毫秒最多生成4096个ID（12位序列号），如果单节点QPS持续超过4096，就会触发 wait_next_millis() 阻塞——这本身是设计行为，不是bug。但实际中容易忽略两点：
立即学习“PHP免费学习笔记（深入）”；
- PHP-FPM 是多进程模型，
static变量不跨进程，每个 worker 都有自己的$sequence，所以必须用 Redis 或共享内存同步状态，否则不同进程间会重复 - 如果用 Swoole 或 ReactPHP 这类常驻进程框架，
static才真正有效，但得确保 worker_id 在整个集群中不重复 - 别用文件锁或 MySQL 自增来保序，性能扛不住，也违背了雪花“无中心协调”的初衷
MySQL 存储 snowflake_id 用什么字段类型？
别用 BIGINT UNSIGNED——虽然它能存 264−1，但 MySQL 5.7 默认开启 sql_mode=STRICT_TRANS_TABLES，插入超限值会报错 Out of range value for column。更安全的做法是：
- 字段类型设为
CHAR(19)（最长19位十进制数），索引效率接近BIGINT，且无溢出风险 - 如果坚持用数值型，MySQL 8.0+ 可用
DECIMAL(20,0)，但查询性能略低 - Laravel/Eloquent 中记得加
protected $casts = ['id' => 'string']，防止 ORM 自动转成 int 导致丢失精度
ID 的高位时间戳特性让其天然支持按时间范围查询，但注意：直接 WHERE id > 1234567890123456789 仍走 B+Tree 索引，和普通主键效率一致，不必额外建时间字段。
