Baseline如何帮助你减少JavaScript的交付量
内容提要
本文介绍如何通过“Baseline”框架审计JavaScript依赖，减少打包体积。作者指出，浏览器已原生支持许多常用库功能，如国际化（Intl）、HTTP请求（fetch）、UI组件（dialog、Popover）及Lodash工具，可节省60-90KB。但Temporal等新特性需谨慎，建议定期检查依赖，用平台API替换旧库，并考虑兼容性。
延伸解读
Baseline 状态决定替换时机
文章强调，替换依赖前需确认原生 API 的 Baseline 状态。Widely available 可放心替换，Newly available 则需评估用户浏览器版本，必要时加特性检测和回退。例如 Intl.DurationFormat 虽已可用，但尚未 Widely available，公共站点需谨慎。
替换前先评估真实成本
并非所有替换都能减小体积。Temporal 虽 API 更优，但当前需引入 19-44KB 的 polyfill，比 dayjs 的 3KB 大得多，反而增加负担。因此，替换前需计算 polyfill 与库的体积对比，并考虑是否可条件加载。
平台 API 并非完全等价
fetch 不自动处理 HTTP 错误、无拦截器、无重试；structuredClone 无法克隆函数和 DOM 节点。替换前需检查实际使用场景，若依赖库的额外功能，需自行封装或保留库。
定期审计依赖，而非一次性清理
浏览器功能持续演进，建议每季度运行一次审计：列出生产依赖、测量体积、检查替代 API 的 Baseline 状态，并应用三个问题评估。这样可逐步减少 60-90KB 的冗余代码，并把握未来如 Temporal 等新特性的替换时机。
Q&A
什么是Baseline？它如何帮助减少JavaScript的交付量？
Baseline是WebDX社区组的一个项目，它标明一个Web功能在主流浏览器（Chrome、Edge、Firefox、Safari）中的可用性状态，分为有限可用、新可用和广泛可用。通过检查依赖的功能是否已达到广泛可用，可以安全地用原生API替换旧库，从而减少打包体积。
在删除JavaScript库之前，应该考虑哪些问题？
在删除库之前，应问三个问题：1. 替代的原生功能对我的用户是否安全（Baseline状态是否适合我的受众）？2. 替换的实际成本是多少（包括polyfill的大小）？3. 原生功能是否覆盖我的实际使用场景（库可能提供额外功能）？
哪些国际化相关的库可以用原生API替代？能节省多少体积？
timeago.js可用Intl.RelativeTimeFormat替代，pluralize可用Intl.PluralRules，numeral可用Intl.NumberFormat，humanize-duration可用Intl.DurationFormat（但后者是新可用状态），列表连接可用Intl.ListFormat。如果使用全套，大约可节省14KB（gzipped）的依赖体积。
fetch能否完全替代axios？有哪些限制？
fetch不能完全替代axios。fetch不会在HTTP错误时拒绝（需要检查res.ok），没有拦截器、自动重试和上传进度。如果只使用简单的GET/POST，可以用fetch加一个薄封装替代axios，节省约17KB（gzipped）。
如何用原生Web API替代模态框、工具提示等UI库？
模态框可以用<dialog>元素替代，它处理焦点陷阱、Escape关闭和焦点恢复，并配合CSS的body:has(dialog:modal){overflow:hidden}锁定滚动。工具提示和弹出面板可以用Popover API和CSS锚点定位替代。这些原生功能通常更易访问，可节省约24KB（gzipped）的依赖。
Lodash的哪些函数可以用原生API替代？
lodash.groupby可以用Object.groupBy或Map.groupBy替代，lodash.clonedeep可以用structuredClone替代，集合操作（union、intersection等）可以用Set的方法替代。但debounce和throttle没有原生替代，仍需保留。
为什么现在不应该用Temporal替代日期库？
Temporal虽然API更好，但尚未达到Baseline状态（Safari未稳定支持），使用它需要引入polyfill，官方polyfill约44KB（gzipped），比dayjs（约3KB）大得多，会使打包体积增加约41KB。因此目前应继续使用dayjs或date-fns，等Safari支持并达到Baseline后再考虑。
如何审计自己的package.json以发现可替换的依赖？
步骤：1. 用npm ls --omit=dev --depth=0列出生产依赖；2. 用Bundlephobia或source-map-explorer测量每个包的大小；3. 在webstatus.dev或MDN上检查替代功能的Baseline状态；4. 应用三个问题（受众安全、成本、功能覆盖）；5. 对广泛可用的功能直接替换，对新可用的功能使用特性检测和回退。
