使用create-react-app构建时出现BigInt转number不允许的错误求助

这个问题的核心是开发环境与生产构建的编译校验、压缩逻辑存在差异——npm start的开发模式对类型转换的检查较为宽松，而npm run build的生产构建会做更严格的代码优化和类型校验，把隐式的BigInt转number操作暴露了出来。下面是具体的排查和解决步骤：

• 定位代码中的BigInt使用场景
  全局搜索项目里的BigInt关键词或数字后缀n（比如123n），重点检查这些值的使用场景：

  • 是否把BigInt直接传给了需要number类型的API？比如Array.slice()、Math系列方法，或是赋值给声明为number类型的变量（TypeScript项目这类问题更明显）。
  • 是否在运算中让BigInt与number隐式混合？比如123n + 456这种写法，开发环境可能静默处理，但生产构建会直接报错。

• 显式处理类型转换（安全优先）
  如果确定BigInt的值在number安全范围内（小于2^53 - 1），可以用Number(bigIntVal)显式转换为number；如果值超出安全范围，不要转成number，要么全程用BigInt处理，要么转为字符串存储传递。示例：

  // 错误写法：隐式转换触发报错
  const page = 100n;
  fetch(`/api/list?page=${page + 1}`); // 1是number，与BigInt相加触发转换
  
  // 正确写法1：值在安全范围时显式转number
  const page = 100n;
  fetch(`/api/list?page=${Number(page) + 1}`);
  
  // 正确写法2：全程使用BigInt
  const page = 100n;
  fetch(`/api/list?page=${page + 1n}`);
  

• 排查依赖包的潜在问题
  如果自身代码中未找到问题，大概率是某个依赖包在生产构建时触发了该转换。可以：

  • 临时移除最近新增的依赖，重新执行npm run build，观察错误是否消失，逐步定位出问题的依赖。
  • 找到问题依赖后，查看其仓库的issue列表，尝试升级到最新版本，或降级至之前的稳定版本。

• 兜底方案：调整构建配置（非优先推荐）
  若上述方法均无效，且你已经eject了项目，可以修改webpack的TerserPlugin配置，禁用相关的类型转换优化；未eject的项目可使用react-app-rewired覆盖配置。但这只是绕过问题，建议优先找到根源后再使用该方案。

内容的提问来源于stack exchange，提问作者David