C#实现短链接需规避三大陷阱：机器ID冲突、时钟回拨、JS数字精度丢失；须动态获取machineId、用Stopwatch替代DateTime、手写Base62并明确字符序、后端返回id_str避免前端解析ID。
直接用 SnowflakeIdGenerator 生成 ID，再用 Base62.Encode 转成字符串，就能得到一个既唯一又紧凑的短链接码。但别急着写死逻辑——机器 ID 冲突、时钟回拨、JavaScript 端数字精度丢失，这三个坑踩一个，线上就可能批量跳错链接。
为什么 C# 里雪花 ID 容易重复？
标准雪花算法依赖 machineId 和毫秒级时间戳。C# 项目常犯两个错误：
- 本地开发时多个实例共用同一
machineId（比如硬编码为1），一上 K8s 就冲突 - 没检测系统时钟是否回拨，NTP 同步后旧时间戳复用，导致同一毫秒内序列号重置，ID 重复
- 未做
datacenterId隔离，多机房混用 ID 段，跨机房部署时悄悄撞车
现象是：数据库报 duplicate key violation，或 Redis 缓存里同一个短码映射到不同长 URL。解决办法不是加重试，而是启动时从 Consul 或 Kubernetes StatefulSet 名称动态读取 machineId，并用 Stopwatch.GetTimestamp() 替代 DateTime.Now.Millisecond 避免系统时钟抖动影响。
C# 的 Base62 编码必须自己写，不能用 NuGet 包
多数开源 Base62 包默认用 0-9a-zA-Z 字符集，但实际部署时你会发现：0 和 O、1 和 l 在二维码或小字体下根本分不清。更糟的是，有些包把字符顺序写反了（比如先大写后小写），导致和 Java/Go 服务端解码不兼容。
正确做法是手写两个静态方法，明确指定字符顺序：
private static readonly string Base62Chars = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
public static string Encode(long num) {
if (num == 0) return "0";
var sb = new StringBuilder();
while (num > 0) {
sb.Append(Base62Chars[(int)(num % 62)]);
num /= 62;
}
return new string(sb.ToString().Reverse().ToArray());
}
public static long Decode(string str) {
long num = 0;
foreach (char c in str) {
int idx = Base62Chars.IndexOf(c);
if (idx == -1) throw new ArgumentException($"Invalid char '{c}' in Base62 string");
num = num * 62 + idx;
}
return num;
}注意：别用 Math.Pow(62, n) 做容量预估——C# 的 double 在 n ≥ 15 时开始丢精度，算出来 62⁸ 是 218万亿，但实际值要拿 BigInteger 算。
前端 JavaScript 解析短码时会丢 ID 最后一位
这是最隐蔽的坑。C# 生成的雪花 ID 是 long（64 位），转成 Base62 后是 8~9 位字符串；但前端 JS 用 parseInt(shortCode, 62) 试图还原时，Number.MAX_SAFE_INTEGER 只能精确表示到 2⁵³ ≈ 9e15，而 62⁸ 已超这个范围。结果就是：后端 ID 是 1847293847293847293，JS 解出来变成 1847293847293847300，查不到原始 URL。
解决方案只有两个：
- 后端返回短码时，同时带一个
id_str字段（字符串形式的原始 ID），前端只传字符串，不转数字 - 放弃在前端还原 ID，所有跳转都走后端重定向接口（
/s/{code}），由服务端完成Base62.Decode和查库
别信“JS 用 BigInt 就能解决”——微信浏览器、iOS Safari 14 以下都不支持，而且你没法控制用户用微信扫码打开还是用 Safari 打开。
真正难的不是写出能跑的代码，而是让 C# 生成的短码，能在 iOS 微信、安卓 Chrome、甚至打印机扫出来的模糊二维码里，稳定还原出原始 ID。字符集选哪个、机器 ID 怎么分、前端要不要碰数字——每个选择都在悄悄放大故障面。
