以前写前端路由，是不是总得装个 React Router 或者 Vue Router？一套 pushState 管前进，一套 popstate 管后退，再加一套手动拦截链接点击，三件事各自为政，写起来就像在缝合三个不同的小系统。过去七八年，这套“缝合怪”几乎躲不掉。就算只做一个内容站点，为了避免整页刷新，你也得先装个路由库。
现在，这一切简化为一个原生事件。
Navigation API：一个统管所有“导航”的动作
以前的路由逻辑长这样：监听 popstate 处理浏览器前进后退，监听 click 捕获所有带 data-route 属性的链接、阻止默认行为、手动推入 history 栈，然后再执行一次初始渲染。三块代码各不关联，错误经常发生在它们交接的地方——比如用户点开链接时，URL 变了但页面没反应，或者按了后退键，列表页竟然没刷新。
有了 Navigation API，这段逻辑变成了：
navigation.addEventListener("navigate", (e) => { const url = new URL(e.destination.url); e.intercept({ handler() { renderRoute(url.pathname); }, }); });
一个事件，一个拦截点。intercept() 告诉浏览器“这次导航交给我，等我完成”，于是浏览器可以自动显示原生加载指示，不需要写一行 spinner 代码。此外，滚动恢复（e.scroll()）、表单数据访问（e.formData）、按历史记录索引跳转（navigation.traverseTo(key)）全部内置，以前的“轮子”一个都不用手动补。
这个 API 在 2026 年初正式跨浏览器可用：Chrome、Edge、Firefox 147 以及 Safari 26.2 均已支持。Baseline 2026 意味着不需要任何 polyfill，生产环境直接能用。
没有“杀死”框架，却砍掉了“过度引进”的动机
Navigation API 出来后，React Router 和 TanStack Router 都没有恐慌，反而公开讨论如何把它作为底层——React Router 的相关讨论串、TanStack Router 的提案，都在探讨用 Navigation API 替换内部长期以来基于 History API 的 workaround。框架依然提供嵌套路由、数据加载、错误边界等上层结构，这是原生 API 不会涉及的领域。
真正被“杀死”的，是那种“我只想做个博客/文档站/几个页面的后台，结果为了不刷新页面而引进一整套路由方案”的妥协。现在平台自己兜底，中小型内容网站终于可以轻装上阵。
当然，Safari 26.2 暂时还不支持 precommitHandler，一些高级拦截模式会受限。另外，规范作者 Ian Hickson 曾把 pushState() 称作自己“最爱的错误”，所以这个替代品要逾越的门槛其实很低——一种充满了行业自嘲的真实感。
容器样式查询：用 CSS 感知自定义属性，无需 JS 辅助
同样在 Baseline 2026 队列里的，还有容器样式查询（container style queries for custom properties）。过去如果想要根据某个 CSS 变量的值动态调整样式，通常得靠 JavaScript 读属性、算尺寸，再暴力改 class。现在浏览器可以直接在样式表里根据自定义属性值进行条件匹配，省掉一层层脚本转换——就像当年容器查询让响应式布局不再依赖视口，这次把“按变量值切换样式”的能力也直接交给了平台。
虽然这个功能目前还没出现与前述路由 API 同样量的代码片段对比，但它的上线逻辑是一样的：之前必须手写的判断逻辑、引入的工具库，现在都可以逐步剥离。
“不再安装这个了”——一个基线年，几个新习惯
热门跟贴