.net 中的 tick 是以 100 纳秒为单位的时间戳，1 毫秒 = 10,000 ticks；直接加减整数即可，但需注意 javascript 数值精度限制导致的大整数截断问题。
net 中的 tick 是以 100 纳秒为单位的时间戳，1 毫秒 = 10,000 ticks；直接加减整数即可，但需注意 javascript 数值精度限制导致的大整数截断问题。
在 .NET 生态中，DateTime.Ticks 表示自 0001-01-01 00:00:00 起经过的 100 纳秒（0.1 微秒）数，因此：
- ✅ 1 毫秒 = 1,000,000 纳秒 = 10,000 ticks
- ❌ 不是
1000ticks（那是常见误解）
你提供的代码逻辑本身正确：
const ticksInMilliseconds = 10000; const startTick = 638315425210000000; const millisecondsAdded = startTick + ticksInMilliseconds; // → 638315425210010000
但问题根源不在计算逻辑，而在 JavaScript 的安全整数边界（Number.MAX_SAFE_INTEGER = 9007199254740991 ≈ 9 quadrillion）。
你使用的 tick 值（如 638315425210000000）已高达 6.38 × 10¹⁷，远超 2⁵³ ≈ 9 × 10¹⁵，此时 JavaScript 的 Number 类型无法精确表示所有个位数字——低位会发生静默舍入。
? 验证示例：
console.log(638315425210000000); // → 638315425210000000（看似正常） console.log(638315425210000000 + 1); // → 638315425210000000（+1 无变化！） console.log(638315425210000000 + 10000); // → 638315425210010000（+10000 有时“碰巧”显示，但不可靠）
这就是为何在线工具 tickstodatetime.azurewebsites.net 对 638315425210010000 仍显示 2023-09-29T00:02:01.000Z —— 它内部可能使用了 BigInt 或高精度解析，而你的 JS 运行时已丢失精度。
✅ 正确解法：全程使用 BigInt 处理大 tick 值
const ticksInMilliseconds = 10000n; // 后缀 n → BigInt const startTick = 638315425210000000n; const endTick = 638338147200000000n; const millisecondsAdded = startTick + ticksInMilliseconds; // 638315425210010000n const millisecondReduced = endTick - ticksInMilliseconds; // 638338147199990000n // 转回字符串供 API 或工具使用（避免 Number 转换） console.log(millisecondsAdded.toString()); // "638315425210010000" console.log(millisecondReduced.toString()); // "638338147199990000"
⚠️ 注意事项：
-
BigInt不能与Number混合运算（如638315425210000000n + 10000会报错），务必统一类型； - 浏览器兼容性：Chrome 67+/Firefox 68+/Safari 14+ 支持，旧环境需 polyfill 或服务端处理；
- 若需转换为
Date，推荐用new Date(Number(tickValue / 10000n))（先降精度到毫秒级），或使用专用库如ticks-to-date。
? 总结：Tick 增减毫秒本身是线性运算（±10000），但 JavaScript 中必须规避 Number 精度陷阱——用 BigInt 是唯一健壮方案。切勿依赖 +/- 对超大十进制字面量的浮点运算结果。
