nextId() 返回的 ID 在 PHP 中可能不是预期整数，因 32 位环境溢出、浮点截断或时钟回拨导致重复或负数；须用 floor(hrtime(true)/1e6) 获取毫秒、抛异常处理回拨、Redis 外置 sequence、全程字符串处理兼容 32 位。
nextId() 返回的 ID 在 PHP 里可能不是你想要的整数——这是最常踩的坑，直接导致 MySQL 插入失败、Redis 键名错乱、前端 JS 解析为 9007199254740992 这类近似值。
hrtime(true) 比 time() 安全，但转换毫秒必须用 floor()
PHP 的 time() 和 microtime(true) 都受系统时钟回拨影响，一调就崩。而 hrtime(true)（PHP 7.3+）返回纳秒级浮点数，本身不回拨，但直接 (int)($ts / 1e6) 强转会因浮点精度丢失少 1 毫秒（比如 1746582391000.999 截断成 1746582391000）。
正确写法是：
$ms = floor($ts / 1000000);- 再跟
$lastTimestamp比较，若$ms <= $lastTimestamp，立刻抛RuntimeException('Clock moved backwards')
别 sleep 等待——高并发下请求会堆积；也别“用上次时间继续生成”，那等于主动造重复 ID。
$sequence 在多进程下必然冲突，不能靠 static 变量兜底
PHP-FPM 或 pcntl_fork() 后，每个 worker 进程都复制了类的内存状态，static $sequence = 0 在各进程里独立计数，同一毫秒极易生成相同 timestamp + worker_id + sequence。
可行方案只有两个：
- 低并发：用文件锁 +
fopen('/tmp/sf_seq.lock', 'c')+flock()读写序列号（注意设置超时防死锁） - 生产环境：走 Redis，
INCR "snowflake:seq:{$workerId}"，再EXPIRE30 秒防堆积
别试图用gmp_add()或bcadd()做序列运算——ID 不参与计算，纯属徒增开销。
64 位 ID 在 32 位 PHP 或 Windows 上会溢出变负数或科学计数法
PHP_INT_SIZE 是 4（32 位）时，1 << 32 就溢出，雪花 ID 拼接后大概率变成负数或 1.23456789E+18 字符串。MySQL 存 BIGINT UNSIGNED 字段时会被截断。
上线前务必执行：
-
php -r "var_dump(PHP_INT_SIZE);"确认输出是8 - 若无法升级，ID 必须全程当字符串处理：
(string) $id返回、数据库字段用VARCHAR(20)、ORM 关闭自动类型转换
别信“用gmp_init()包一层就安全”——只要最后存进 MySQL 的是 float 或截断 int，问题照旧。
真正难的不是写对逻辑，而是让 $lastTimestamp 和 $sequence 在进程、容器、K8s Pod 重启这些真实场景里始终可依赖。本地测试跑通 1000 并发不重复，不等于线上不出问题。
