Skip to content
Published on

Web 平台 2025 完全攻略：Container Queries・:has()・CSS Nesting・Subgrid・Popover API・Anchor Positioning・WebGPU・WASI・Speculation Rules・Baseline 2024-2025 — Season 6 Ep 5

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
필사 모드
分享
Authors

前言 · 平台变大，框架就变轻

2014-2020 年，我们之所以需要 React・Vue・Angular，是因为浏览器欠缺得太多。组件・状态管理・动画・路由・布局・交互，全都得用 JS 解决。

2024-2025 年不一样了。浏览器把大部分事情都做了。

  • Container Queries 让组件自身就能响应式
  • :has() 让你无需 JS 就能基于子元素选择父元素
  • CSS Nesting・Subgrid 降低了对 SCSS 的需求
  • Popover API・Dialog 把模态框库的必要性降到最低
  • Anchor Positioning 让 Floating UI 原生化
  • View Transitions 让页面切换原生化
  • WebGPU 带来高性能图形与 ML
  • Speculation Rules 带来预渲染与预取

我们依然在用 Next.js・React，但 2025 年的原则是 “能交给平台的就交给平台”。这篇文章就是那张地图。

第1章 · Baseline — 兼容性的新语言

什么是 Baseline？

2023-2024 年由 Web DX Community Group 建立的浏览器功能兼容性标签体系。用来回答“这个功能现在用安全吗？”。

三个级别

Baseline Newly available

  • 已经登陆最近的主流浏览器（Chrome・Edge・Firefox・Safari）
  • 面向最新版本

Baseline Widely available

  • 从上述状态起经过了 30 个月
  • 事实上所有活跃浏览器都支持
  • 可以放心使用

Limited availability

  • 只有一两家主流浏览器支持
  • 生产环境使用需谨慎

实战用法

  • MDN・caniuse・web.dev 上都会显示 Baseline 标签
  • Next.js・Astro・Vite 引入了 target: baseline-2024 这类选项
  • 在公司内部编码指南里声明“只有 Baseline widely available 才不加 polyfill”

为什么重要

  • 取代“支持 IE・现代浏览器”这类含糊的标准
  • 团队内部的决策更快、更明确
  • 成为生产稳定性与 PWA 的质量基准

第2章 · Container Queries — 响应式的革命

传统的问题

媒体查询 @media 以 整个视口 为基准。但同一个卡片组件，有时放在侧边栏、有时放在主区域，尺寸就不一样。哪怕视口相同。

解决：@container

.card-grid {
  container-type: inline-size;
  container-name: grid;
}

@container grid (min-width: 600px) {
  .card { display: flex; }
}

现在卡片布局由卡片网格 自身的宽度 决定。

单位

  • cqw, cqh: container width/height
  • cqi, cqb: inline/block
  • cqmin, cqmax

2025 年的支持情况

  • Chrome 105+・Safari 16+・Firefox 110+ 全都是 Baseline Widely available
  • 事实上已是 基础工具

使用模式

(1) 自身响应式的组件

  • 与被复用在哪里无关

(2) Style Queries（2024 Chrome/Edge）

  • @container style(--theme: dark) — 基于父元素样式属性的条件

(3) 视口 + 容器的组合

  • 页面布局用媒体查询，组件用容器查询

第3章 · :has() — 父选择器的到来

为什么是革命

CSS 一直是只能 向下 走的选择器。基于子元素来给父元素设样式必须靠 JS。:has() 拿掉了这个限制。

使用示例

(1) 按子元素有无来设置父元素样式

.card:has(img) { padding-top: 0; }
.form:has(input:invalid) { border: 1px solid red; }

(2) 按子元素状态设置整体样式

body:has(dialog[open]) { overflow: hidden; }

(3) 兄弟关系

label:has(+ input:focus) { color: blue; }

支持情况

  • Chrome 105+, Safari 15.4+, Firefox 121+ — Baseline Widely
  • 过去对性能的担忧已经解决

实战影响

  • 那些用 JS 操作 parent 类名的代码可以 大量删除
  • 交互状态的 UI 变得简洁得多
  • React 组件里许多“状态 prop”都转移到了 CSS

第4章 · 原生 CSS Nesting

此前

  • 用 SCSS・Less・Stylus 做 nesting
  • 依赖构建工具，有学习曲线

2023-2024 的原生 Nesting

.card {
  padding: 1rem;

  & .title {
    font-size: 1.5rem;
  }

  &:hover {
    background: #f0f0f0;

    & .title { color: #333; }
  }

  @media (min-width: 768px) {
    padding: 2rem;
  }
}

注意

  • 最新规范里 & 选择器 可以省略（2024 年修订）
  • 与旧语法（& ）混用要当心
  • 用 PostCSS Preset-Env 做回退转译

支持情况

  • Chrome 120+・Safari 17.2+・Firefox 117+ — Baseline 2023-2024

意义

  • 对 SCSS 的需求大幅下降
  • 对 CSS-in-JS 的依赖下降
  • Vanilla CSS 的复兴

第5章 · CSS Subgrid

传统 Grid 的局限

  • 就算把子 grid 放进父 grid，行/列也不会对齐
  • 卡片的标题・正文・CTA 很难对齐

Subgrid 的解法

.parent {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
}

.child {
  display: grid;
  grid-template-columns: subgrid; /* 继承父级网格 */
}

现在子 grid 会对齐到父 grid 的轨道上。

使用场景

  • 卡片列表的标题・正文・页脚自动对齐
  • 多列表单
  • Masonry（瀑布流）布局

支持情况

  • Firefox 71+（2019 年起支持）, Safari 16+, Chrome 117+ — Baseline 2023

第6章 · Popover API・Dialog Element

传统模态框的问题

  • 焦点管理靠手写
  • 滚动锁定靠 JS
  • ESC 关闭靠手写
  • 无障碍 ARIA 得自己来

<dialog>（HTML5）

  • 模态与非模态都支持
  • 原生 focus trap
  • showModal() / close() 方法
  • 按 ESC 自动关闭
  • 支持 ::backdrop 样式

Popover API（2024-2025）

<button popovertarget="menu">菜单</button>
<div id="menu" popover>
  <ul>
    <li>项目 1</li>
    <li>项目 2</li>
  </ul>
</div>
  • 一个 popover 属性就是一个弹出层
  • 自动渲染到 Top Layer（不用担心 z-index）
  • Auto-hide（点击外部・ESC）
  • 用 popover="manual" 做手动控制

支持情况

  • Chrome 114+・Safari 17+・Firefox 125+ — Baseline 2024

实战影响

  • 用 Headless UI・Radix Dialog/Popover 的必要性下降
  • 原生 + 少量 CSS/JS 就够了

第7章 · CSS Anchor Positioning

问题：浮动 UI

要把提示框・下拉菜单・弹出层相对某个元素 精确定位 很复杂。

  • 必须依赖 Floating UI（Popper.js）这类库
  • 随着 resize・scroll 要用 JS 重新计算

解决：CSS Anchor Positioning（2024-）

<button id="btn">点击</button>
<div popover style="position-anchor: --btn;">
  提示框
</div>

#btn { anchor-name: --btn; }

[popover] {
  position: absolute;
  top: anchor(--btn bottom);
  left: anchor(--btn left);
}
  • 只用 CSS 就能做锚点定位
  • 自动重定位（fallback）
  • 性能・无障碍都内置

支持情况（2025 年 4 月）

  • Chrome 125+：稳定
  • Safari：开发中（2025 年下半年）
  • Firefox：开发中

影响

  • Popper・Floating UI 的使用下降
  • React 的树结构变简单
  • 不过目前还需要 polyfill（在 Safari 支持之前）

第8章 · Web Components 在 2025 年的现状

三大基础

  • Custom Elements
  • Shadow DOM
  • HTML Templates

2024-2025 年的成熟

(1) Declarative Shadow DOM

  • 服务端渲染时可以包含 Shadow DOM
  • SSR 成为可能

(2) Form-associated Custom Elements

  • 自然融入标准表单
  • formAssociated = true、ElementInternals API

(3) CSS :state() 伪类

  • 从 CSS 里选择自定义状态

与框架的集成

  • React 19 改进了对 Custom Elements 的支持（区分 attributes 与 props）
  • Lit・Stencil 已经成熟
  • Vue・Svelte 天然集成

现实评价

优点

  • 框架中立（设计系统・嵌入式组件）
  • 长寿（浏览器标准）

局限

  • 没有 React 组件那种量级的生态
  • SSR・水合很复杂
  • 主要局限在 共享库・内嵌组件 上

适合的用途

  • 多个团队共享的“Button/Icon 库”
  • 嵌入外部站点的组件（评论・聊天）
  • Shopify・WordPress 之类的插件

第9章 · WebGPU 的现状

WebGL 的局限

  • 基于 OpenGL ES，结构陈旧
  • 并行计算受限
  • 对游戏・AI 来说不够

WebGPU（2023-）

  • 现代 GPU API（Vulkan・Metal・DX12 级别）
  • 支持 Compute Shader → 通用 GPU 计算
  • 一套 API 支持多种操作系统

2024-2025 的主要用途

(1) 在浏览器里跑 AI/ML

  • Transformers.js：在浏览器里推理 Whisper・Llama 等
  • ONNX Runtime Web：GPU 加速
  • MLC-LLM：连 7B 模型也能在浏览器里跑

(2) 高性能图形

  • 基于 WebGPU 的 3D 引擎（Three.js, Babylon.js）
  • 游戏・虚拟展厅

(3) 数据可视化

  • 大规模点云・超越 WebGL 的性能

支持情况

  • Chrome 113+・Edge 113+ 稳定
  • Safari 18+・Firefox Nightly（2025 年进行中）

局限

  • 移动端支持还只是部分支持
  • 内存管理复杂

第10章 · File System Access API・其他本地能力

File System Access API

  • 在浏览器里 直接打开/保存本地文件
  • 超越传统的 <input type="file">，可以 持续访问・修改
  • 对 Photopea・VS Code Web・Figma 这类应用是必需的

2024-2025 的主要新 API

(1) Clipboard API 的进化

  • 支持图片・富文本

(2) Web Share API

  • 操作系统原生的分享面板

(3) Wake Lock API

  • 防止屏幕熄灭（做饭・会议类应用）

(4) Screen Capture・WebCodecs

  • 视频・音频的低层操作

(5) Compression Streams

  • 原生 gzip・deflate

(6) Web Locks

  • 跨标签页的互斥锁・资源协调

局限

  • 一部分需要 PWA 或额外设置
  • Safari・Firefox 的支持存在差异

第11章 · WebAssembly・WASI 2025

WASM 的现状

  • 在 大多数移动端・桌面端浏览器 上有接近原生的性能
  • 与 JS 的高速 interop（WASM SIMD、引用类型、Exception Handling）
  • 语言：Rust, Go, C/C++, AssemblyScript, Zig，Kotlin・Swift 处于实验阶段

WASI（WebAssembly System Interface）

在浏览器之外・在服务器上运行 WASM 的标准。

  • WASI Preview 2（2024）— 组件模型
  • wasmtime・wasmer・WasmEdge 运行时

实战用法

(1) Serverless 边缘

  • Cloudflare Workers, Fastly Compute@Edge, Vercel WASM
  • 冷启动・隔离・多语言

(2) 插件系统

  • Figma Plugins, Shopify Functions, Envoy Proxy
  • 安全隔离用户代码

(3) 浏览器内的重计算

  • 图片・视频编辑，ML 推理，模拟器

韩国的落地案例

  • Naver Whale：基于 WASM 的扩展
  • KakaoTalk Web：部分功能用 WASM
  • Toss：在考虑把安全・核心逻辑放进 WASM

第12章 · Speculation Rules API

目的

  • 预先加载用户接下来要去的页面
  • prerender・prefetch 的标准

示例

<script type="speculationrules">
{
  "prerender": [
    { "source": "list",
      "urls": ["/next-page", "/likely-next"] }
  ],
  "prefetch": [
    { "source": "document",
      "where": { "href_matches": "/articles/*" } }
  ]
}
</script>

模式

  • prefetch：只取资源，不执行
  • prerender：整页渲染（最快，但成本更高）

2024-2025 的现况

  • Chrome 121+・Edge 121+ 稳定
  • Safari・Firefox 开发中
  • Chrome Prefetch Hints 基于数据做自动推荐

实战用法

  • Next.js・Astro 正在考虑从后端自动注入
  • 大企业的新闻・电商开始用起来了

注意

  • 成本（CPU・网络）
  • 分析工具里的“假访问”问题

第13章 · 实战 · “平台优先”检查清单

做新组件・新功能时，在框架和库之前 先确认这些。

检查项

  • 响应式：Container Queries 能做吗？
  • 状态样式：用 :has()・:focus-within 行不行？
  • 模态框・弹出层：<dialog>・Popover API？
  • 提示框・下拉菜单：Anchor Positioning？
  • 表单有效性：:user-invalid・:user-valid？
  • 侧边抽屉：<details> + 样式？
  • 文件：File System Access？
  • 计数器・数字变化：CSS @property 动画？
  • 滚动效果：Scroll-driven Animations？
  • 页面切换：View Transitions？

判断顺序

  1. Web 平台里有没有内置能力？
  2. 是不是 Baseline Widely 支持？
  3. 没有的话，能不能用轻量库替代？
  4. 仍然需要的话，才用框架组件

第14章 · 下期预告 — Season 6 Ep 6：“性能・Core Web Vitals 2025”

把 Web 平台的能力用好，就是把 性能 用好。Ep 6 讲 Core Web Vitals 与性能全貌。

  • LCP・CLS・INP（FID 的继任者）
  • Real User Monitoring 与 Synthetic Test
  • Critical Rendering Path，LCP 优化
  • JS 包体瘦身（Rollup・esbuild・swc）
  • Image 优化（Next/Image・Astro Image・AVIF）
  • Font 优化（font-display・可变字体・子集化）
  • Caching 策略（Cache-Control・Service Worker）
  • Edge・CDN・HTTP/3
  • Vercel Speed Insights・CrUX・PageSpeed
  • 2025 年移动端低功耗下的性能
  • 韩国用户的网络特性（地铁・5G）

“性能不是功能。它是所有功能的前提。”

下篇文章再见。

结语 · 检查清单 12

  1. 你是按 Baseline Widely 这个标准来决定要不要用某个功能的吗？
  2. 需要响应式时，你会先考虑 Container Queries 吗？
  3. 基于父元素的样式，你会用 :has() 吗？
  4. 你的 CSS 是靠 Nesting 而不是构建工具在管理的吗？
  5. 复杂布局你会用 Subgrid 吗？
  6. 模态框・弹出层你是用 原生 API 实现的吗？
  7. 提示框・下拉菜单的位置你会用 Anchor Positioning 吗？
  8. 你会把 Web Components 用在 共享库 上吗？
  9. 你在探索 WebGPU 的机会（AI・可视化）吗？
  10. 需要本地能力（文件・系统）时，Platform API 是不是排在最前面？
  11. 你用 Speculation Rules 评估过预取/预渲染吗？
  12. “平台优先”检查清单，你会 对每个新组件 都套用吗？

“好的工程师知道平台能做什么。 伟大的工程师知道什么时候交给平台，什么时候自己动手。”

— Season 6 Ep 5, Fin.

Discuss on Twitter • View on GitHub