Temporal API 目前处于 TC39 提案 Stage 3 阶段，尚未在所有浏览器原生支持，直接替代 Moment.js 需要引入 polyfill 或重构代码，迁移成本较高，适合新项目或能接受打包体积增加的场景。
先说结论：生产环境直接迁移 Temporal API 风险较大，建议优先评估 date-fns 或 Luxon 作为中间方案，除非项目强依赖原生时区精度且能承担 polyfill 开销。
- 适合：新项目初始化或对时区计算精度有严格要求的场景
- 重点看：浏览器兼容性列表和 polyfill 引入后的 bundle 体积变化
- 别忽略：Moment.js 可变对象与 Temporal 不可变对象的设计差异会导致逻辑重构
快速处理思路
没有一键迁移命令，需按代码扫描、环境评估、方案选型、重构测试四步走。先使用代码扫描工具统计 Moment.js 调用点，再根据目标用户浏览器分布决定是否引入 polyfill，最后分批重构日期逻辑并回归测试。
为什么会这样
Moment.js 已进入维护模式不再新增功能，而 Temporal API 是旨在解决 Date 对象缺陷的原生提案但尚未正式标准化。Moment.js 官方自 2020 年 9 月起进入维护模式，只修复严重 Bug 不开发新功能。Temporal API 处于 TC39 提案 Stage 3 阶段，部分浏览器实验性支持，生产环境需依赖 polyfill 实现兼容。
分步处理
按以下顺序执行迁移评估，每步完成后记录风险点以便回滚。
1. 扫描代码库中所有 moment 调用点，统计使用频率和涉及功能（如时区、格式化、相对时间）。
2. 检查目标用户浏览器分布，确认对 Temporal API 原生支持的比例，公开资料中没有看到可靠的量化数据说明具体覆盖率。
3. 选择替代方案，若必须用 Temporal 则安装 temporal-polyfill，若求稳则迁移至 date-fns 或 Luxon。
4. 分批重构代码，优先重构非核心业务的日期处理逻辑，保留 Moment.js 作为回滚备份。
怎么验证是否生效
通过单元测试覆盖率、打包体积监控和运行时错误日志三方面验证。运行现有日期相关单元测试，确保重构后断言全部通过。检查构建产物大小，确认 polyfill 或新库未导致体积超限。监控生产环境控制台日志，观察是否有 Temporal 相关 API 调用报错。
常见坑
注意不可变性差异、时区默认行为变化和 polyfill 兼容性限制。Temporal 对象是不可变的，而 Moment.js 对象是可变的，直接赋值引用会导致逻辑错误。Temporal 默认处理时区更严格，可能暴露原有代码中隐式依赖本地时区的 Bug。Polyfill 在旧版 Node.js 或特定构建工具链中可能需要额外配置。
常见问题
Temporal API 现在稳定吗？
尚未正式稳定，处于 TC39 Stage 3 提案阶段。虽然 API 设计已相对固定，但浏览器原生支持尚未普及，生产环境使用需配合 polyfill。
有没有比 Temporal 更成熟的替代方案？
有，date-fns 和 Luxon 是目前更成熟的社区方案。这两个库功能稳定、社区活跃且无需 polyfill 即可在所有主流环境运行。
迁移后时区处理会有什么变化？
Temporal 显式要求指定时区，不再隐式依赖系统本地时区。原有依赖系统默认时区的代码需要显式传入时区参数，否则计算结果可能不一致。
参考来源
- Moment.js 官方文档，Project Status，https://momentjs.com/docs/#/-project-status/
- TC39 Proposal Temporal 仓库，Stage 3 状态说明，https://github.com/tc39/proposal-temporal
- Can I use 兼容性查询，Temporal 支持情况，https://caniuse.com/?search=temporal