BigInt可精确表示64位文件偏移量，但Node.js fs API不原生支持，需用BigInt做地址计算后转为安全number调用I/O，超范围时应降级流式读取或报错。
BigInt 可以精确表示大于 Number.MAX_SAFE_INTEGER（2⁵³−1）的整数，因此适合处理 64 位文件偏移量（如 Windows 的 LARGE_INTEGER 或 Linux 的 off_t 在 LP64 模型下为 64 位）。但需注意：JavaScript 的 fs API（包括 Node.js v20+）**原生不接受 BigInt 作为文件位置参数**，直接传入会报错。实现“基于 BigInt 的随机访问逻辑”，关键在于**用 BigInt 做地址计算与管理，再安全转为可用类型调用底层 I/O**。
理解 64 位偏移量的表示边界
64 位有符号整数范围是 −2⁶³ 到 2⁶³−1（即 −9,223,372,036,854,775,808 到 9,223,372,036,854,775,807）。BigInt 能无损表达该范围任意值：
-
// 正确：BigInt 支持字面量后缀 n
const offset = 1234567890123456789012345678901234567890n; -
// 也可从字符串或数字转换（注意：大数字字面量用字符串避免精度丢失）
const offset2 = BigInt("9223372036854775807"); // 最大有符号 int64 -
// 错误：直接写超安全整数的数字字面量会丢失精度
const bad = 9223372036854775807; // 实际是 9223372036854776000
将 BigInt 偏移量适配到 Node.js fs API
Node.js 的 fs.read()、fs.write()、fs.promises.readFile() 等方法的 position 参数只接受 number | null | undefined，且要求 ≤ Number.MAX_SAFE_INTEGER（约 9e15）。因此不能直接传入 >2⁵³ 的 BigInt。解决路径是：
-
若偏移量 ≤ 2⁵³−1：直接用
Number(bigInt)转换（安全） -
若偏移量 > 2⁵³−1（常见于超大文件）：
✓ 使用fs.createReadStream()/fs.createWriteStream()配合options.start（仅支持 number，仍受限）
✓ 更可靠方式：用fs.open()获取文件描述符，再通过fs.read(fd, ...)+fs.write(fd, ...)并结合fs.fstat()校验，**但 position 仍需 number** —— 这说明纯 JS 层无法绕过 Number 类型限制 -
真正支持任意 64 位 offset 的方案：使用原生绑定（如
node-addon-api）或 WASM 调用系统pread64/pwrite64；或借助ffi-napi调用 libc 函数（Linux/macOS）或 WinAPI（Windows）
实用的 BigInt 偏移管理逻辑（不依赖底层扩展）
即使无法直接用 BigInt 调用 I/O，仍可利用它做高精度地址运算、分块校验、索引构建等：
-
大文件分块定位：将 64 位 offset 拆为「块号 + 块内偏移」，块大小设为 2³²（4GB），则块号 =
offset / 2n**32n，块内偏移 =offset % 2n**32n，两者均可转为 safe number 处理 -
多段偏移聚合：例如合并多个日志段的起始位置，用 BigInt 累加避免浮点误差
const totalStart = seg1Start + seg2Start + seg3Start; -
偏移合法性检查：读取文件大小后（
BigInt((await fs.stat(path)).size)），用 BigInt 进行范围判断
if (offset = fileSize) throw new Error("Out of bounds");
未来兼容性提示
Node.js 官方已在跟踪 BigInt 文件位置支持（见 issue #44914）。若你控制运行环境，可关注 v22+ 是否引入 position: bigint 选项。当前最稳妥做法是：用 BigInt 做所有地址建模与计算，I/O 调用前做范围断言，并对超出 Number.MAX_SAFE_INTEGER 的场景降级为流式读取或报明确错误。
