直接用 snowflakeidgenerator 类易出错，因c#无官方实现，常见问题包括时间回拨处理粗暴、机器id写死、高并发下序列号未原子自增导致id重复；需用interlocked.increment、utcnow、动态获取worker id并校验时间回拨。
为什么直接用 SnowflakeIdGenerator 类容易出错
因为 C# 没有官方内置的雪花算法实现，网上很多“开箱即用”的类要么时间回拨处理粗暴（直接抛异常），要么机器 ID 写死成 1，一上多节点就重复。更隐蔽的问题是：DateTimeOffset.UtcNow.ToUnixTimeMilliseconds() 在高并发下可能返回相同时间戳，导致同一毫秒内生成多个 ID 时，序列号（sequence）没正确自增或重置，ID 就撞车了。
实操建议：
- 自己实现时，必须用
Interlocked.Increment更新 sequence，不能用普通++ - 时间戳提取别用
DateTime.Now，它精度低且受系统时钟调整影响大；固定用DateTimeOffset.UtcNow.ToUnixTimeMilliseconds() - 机器 ID 别硬编码，从配置或环境变量读取，比如
Environment.GetEnvironmentVariable("WORKER_ID") - 初始化时检查当前时间是否小于上次生成时间，若小于，必须等待至少 1ms 或进入“等待回拨”逻辑（非阻塞式重试）
如何让雪花 ID 支持容器化部署（K8s / Docker）
在 K8s 里 Pod 可能被调度到任意节点，IP 和主机名不可靠，靠 Dns.GetHostName() 或 Environment.MachineName 拿 worker ID 极易冲突。真正可行的是把 worker ID 绑定到稳定标识上。
实操建议：
- 优先使用 K8s Downward API 注入
POD_NAME或CONTROLLER_REVISION_HASH，再做哈希取模：比如Math.Abs(podName.GetHashCode()) % 1024 - 若用 Docker Compose，可在
docker-compose.yml中通过environment:显式传入WORKER_ID=5 - 避免用 IP 的最后一位当 worker ID——容器网络中 IP 可能动态分配，且不同网段最后一位可能重复
- 预留至少 10bit 给 worker ID（支持 0–1023），别为了省位数压到 5bit（仅 32 个）
long 类型 ID 在 EF Core 里怎么映射不翻车
EF Core 默认把 long 当成数据库的 BIGINT，看着没问题，但一旦你用雪花 ID 做主键又开了迁移（dotnet ef migrations add），EF 可能悄悄给你加 ValueGeneratedOnAdd()，结果插入时数据库自增和代码生成的 ID 冲突，报 Cannot insert explicit value for identity column。
实操建议：
- 实体类中明确标注：
[DatabaseGenerated(DatabaseGeneratedOption.None)]，告诉 EF “这 ID 我自己管” - 如果用 Fluent API，在
OnModelCreating里写：modelBuilder.Entity<order>().Property(e => e.Id).ValueGeneratedNever();</order> - 别在数据库建表时设
IDENTITY，雪花 ID 必须是非自增主键 - MySQL 用户注意：确保字段是
BIGINT UNSIGNED，否则最大值卡在 9223372036854775807，而标准雪花 ID 最大值约 9007199254740992（JavaScript 安全整数上限），虽不超long，但为兼容前端 JS，建议控制在ulong范围内并存为无符号类型
时间回拨问题不是“等 1ms”就能解决的
服务器 NTP 同步、虚拟机暂停、手动调时间都可能导致时间回拨。简单 sleep(1) 不仅阻塞线程，还可能错过下一个毫秒窗口，尤其在低负载时 sequence 归零后，同一毫秒内只能发 1 个 ID，吞吐暴跌。
实操建议：
- 记录上一次生成时间戳（
_lastTimestamp），每次生成前比较；若回拨 ≤ 5ms，用Thread.Sleep等待至原时间点之后；若 >5ms，直接抛异常并告警（说明系统时钟严重异常） - 别用
Stopwatch替代系统时间——雪花算法依赖全局一致的时间基线，Stopwatch 是相对计时器，跨进程/跨机器无意义 - 生产环境务必开启 NTP 服务并配置 panic threshold（如 chrony 的
makestep 1.0 -1），让时钟跳跃时自动校正而非缓慢追赶 - 如果业务允许，可考虑降级方案：回拨期间临时切到 UUIDv4（带时间戳前缀），但需保证下游能识别并排序
最麻烦的其实是测试——本地开发机频繁休眠会导致回拨误报，建议单元测试里用可替换的 IClock 接口，注入模拟时间源，而不是直接调 DateTimeOffset.UtcNow。
