19.5KB 对比 52.1KBtemporal-polyfill 与 js-temporal/polyfill 的终极对决【免费下载链接】temporal-polyfillA lightweight polyfill for Temporal, successor to the JavaScript Date object项目地址: https://gitcode.com/gh_mirrors/tempo/temporalJavaScript 的Date对象问题多多而 Temporal 正是它的现代继任者。temporal-polyfill 是一款轻量级、符合规范的 Temporal polyfill压缩后 gzip 仅19.5KB而官方 js-temporal/polyfill 却要52.1KB——体积相差 167%。本文将从包体积、规范符合度、日历支持、安装方式四个维度为选择 Temporal polyfill 的你提供一份完整对比指南。为什么需要 Temporal polyfillTemporal 是 TC39 提出的新一代日期时间 API目标是彻底取代饱受诟病的Date对象时区混乱、无法表示日期只有毫秒时间戳、修改操作会改变原对象……而 Temporal 提供了PlainDate、PlainDateTime、ZonedDateTime、Instant、Duration等类型语义清晰、不可变、完全符合 ISO 8601。但遗憾的是原生 Temporal 尚未在所有浏览器中落地Safari 和较旧环境仍然缺失因此polyfill垫片成为前端开发者提前体验 Temporal 的唯一方式。而 polyfill 的体积直接影响页面加载性能。终极对决包体积数据对比 体积对比数据来自项目官方基准测试 size-comparison/RESULTS.md全部使用 Terser 压缩后 gzip 测量保证苹果对苹果包基础日历gzip全部日历gziptemporal-polyfill19,532 B23,378 Bjs-temporal/polyfill52,136 B167%52,136 B123%⚠️ 注意js-temporal/polyfill 没有基础/全量日历的拆分单一 bundle 永远包含所有日历所以两列数值相同。结论同样只使用 iso8601 和 gregory 日历temporal-polyfill 比对手小 62%省下的 32.6KB 在移动端、低配设备上就是实打实的性能优势。体积差距从何而来三大根源 1. BigInt 实现策略真实 bigint vs JSBIjs-temporal/polyfill 内部依赖 JSBI 的对比表在 2020 年后的浏览器中 bigint 是原生能力无需携带任何模拟层。2. 日历系统按需拆分basic / full 双构建temporal-polyfill 提供了basiciso8601 gregory和full14 种扩展日历两套入口。绝大多数业务只需要 ISO 日历只用 basic 版即可省下约 3.8KB而 js-temporal/polyfill 永远打包全部日历没有选择权。这正是 19.5KB vs 52.1KB 数字背后的设计哲学差异。3. 规范的时间差从 polyfill/CHANGELOG.md 可以看到temporal-polyfill v1.0.2 已对齐2026-07-27 最新规范仅剩 2 处刻意偏离见 test262-expected-failures/shim.txt并持续跟进 spec 演进而 js-temporal/polyfill 停留在 2025 年 3 月的规范快照。更新的规范往往意味着更精简的内部实现如算法化日历运算取代脆弱的 Intl 数据抓取。功能全面对比不止是体积 维度temporal-polyfilljs-temporal/polyfill规范日期2026-072025-03全局安装✅ ESM CDN 均可❌ 不支持日历支持basic 2 种 / full 14 种全部打包原生 Temporal 优先✅ 有则自动使用仅旧版行为tree-shakeable 函数 API✅ 内置❌ 无最低环境Chrome 67 / Node 16类似其中全局安装是很多项目的刚需temporal-polyfill/global入口会检测原生 Temporal有则直接用原生没有才注入 polyfill真正做到渐进增强。体积敏感场景的终极武器tree-shakeable API 如果 19.5KB 还不够小temporal-polyfill 还内置了一套可摇树tree-shakeable函数式 API位于 docs/fns/index.md。它把每个 Temporal 操作拆成独立函数作用于普通记录对象打包器只保留你真正 import 的函数import * as PlainDateFns from temporal-polyfill/fns/PlainDate const date PlainDateFns.create(2026, 6, 1) const later PlainDateFns.addMonths(date, 2) PlainDateFns.toString(later) // 2026-08-01每个类型都有独立入口temporal-polyfill/fns/ZonedDateTime、fns/Duration等。对于日期选择器、调度器这类组件库作者来说把它作为 peer dependency 共享宿主应用和组件共用同一份内部实现不再重复打包——这正是 for-component-authors.md 描述的共享而非复制模式。上手安装最快配置方法 ⚡npm install temporal-polyfill最常见的全局入口只需一行导入见 polyfill/README.mdimport temporal-polyfill/global Temporal.Now.zonedDateTimeISO().toString() // 2026-08-20T07:47:32-04:00[America/New_York]入口选择速查表temporal-polyfill/global— 全局 polyfill原生优先大多数人选这个temporal-polyfill— 本地导入无副作用ponyfill 风格temporal-polyfill/implementation— 强制使用内置实现temporal-polyfill/shim— 按条件手动安装temporal-polyfill/full/global— 需要佛历、农历等扩展日历浏览器直接使用 CDN 引入也是支持的具体可参考 polyfill/README.md 的 CDN 章节。TypeScript 用户注意TS 6.0 在tsconfig.json里加lib: [esnext]即可更早版本需要额外导入temporal-polyfill/types/global。未来迁移路径不是死胡同 选择 temporal-polyfill 的 tree-shakeable API 并不会被锁死。项目配套了 codemod/README.md 中的temporal-polyfill-codemod迁移工具npx temporal-polyfill-codemod fns-to-temporal path当原生 Temporal 覆盖所有目标环境后一条命令就能把PlainDateFns.addMonths(date, 2)机械地重写为date.add({ months: 2 })依赖随即消失。它非常保守无法确定的代码会保留并报告让 CI 拦截不完整的迁移——无痛退出这正是能进能退的设计。总结该如何选择追求极致体积、需要全局安装、希望组件库可共享→ 选temporal-polyfill19.5KB 起步还有 tree-shakeable API 兜底深度依赖非 ISO 日历如农历、日本历且不关心体积→ js-temporal/polyfill 也可用但注意它无法全局安装两者都能用但不确定→ 直接上 temporal-polyfill更小、更新、更符合最新规范且未来的退出路径codemod已经铺好。在 Web 性能日益被重视的今天每 1KB 都弥足珍贵。19.5KB vs 52.1KB不是简单的数字差异而是两种工程哲学的胜负手。选择 temporal-polyfill就是选择把体积控制权握在自己手里。【免费下载链接】temporal-polyfillA lightweight polyfill for Temporal, successor to the JavaScript Date object项目地址: https://gitcode.com/gh_mirrors/tempo/temporal创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考