星舞互娱

把一帧画面拆开看：浏览器渲染流水线完全指南

Mon, 12 Oct 2026 02:10:00 +0000

几乎每一次"页面怎么这么卡"的讨论，最后都会落到同一个问题上：你到底在第几步花了时间？

渲染流水线并不是一个抽象的比喻，它是一条真实存在、可以被逐帧观测的链路。理解它，你就不需要靠猜来优化性能。

# 五个阶段，一条流水线

从按下回车到看见像素，浏览器大致会经历：

Parse —— 字节流变成 DOM，CSS 变成 CSSOM
Style —— 为每个节点计算最终样式（Recalculate Style）
Layout —— 计算几何位置，输出盒模型坐标
Paint —— 填充像素，生成绘制指令
Composite —— 分层合成，交给 GPU 上屏

关键在于：后面的阶段依赖前面的阶段。你改一个属性，触发的阶段越靠后，代价越小。

# 三种改动，三种代价

你改了什么	触发的阶段	代价
`width`、`top`、字体大小	Layout → Paint → Composite	最贵
`background-color`、`box-shadow`	Paint → Composite	中等
`transform`、`opacity`	Composite	最便宜

所以动画优先用 transform 和 opacity，不是为了"玄学更丝滑"，而是因为它们真的跳过了前两个阶段。

/* 会触发 Layout 的写法 */
.card:hover { left: 4px; }

/* 只走合成层的写法 */
.card {
  transition: transform 240ms cubic-bezier(.22,.61,.36,1);
  will-change: transform;
}
.card:hover { transform: translate3d(0, -4px, 0); }

注意：will-change 是一把双刃剑。它会让元素提前被提升为合成层，滥用会吃掉显存，反而拖慢整体帧率。只在真正会动的元素上加，动画结束后考虑移除。

# 强制同步布局：最隐蔽的性能杀手

有一种写法看起来无害，却会让浏览器在同一帧里反复重排：

// 每轮循环都在强制 Layout
for (const el of list) {
  el.style.width = el.offsetWidth + 10 + 'px';
}

读取 offsetWidth 会强制浏览器"立刻"把待处理的样式变更刷新成布局结果。写在循环里，就是 O(n) 次同步布局。

修法很简单：先读后写。

// 1. 一次性读完
const widths = list.map((el) => el.offsetWidth);
// 2. 再统一写
list.forEach((el, i) => { el.style.width = widths[i] + 10 + 'px'; });

# 怎么用 DevTools 抓到真凶

打开 Performance 面板，录制一段交互，然后看主线程的火焰图：

黄色块里出现紫色的 Layout，说明重排了
绿色 Paint 密集出现，说明绘制压力大
底部 Frames 出现红色三角，那一帧就超时了（>16.7ms）

把时间花在读数上，而不是花在猜上。

# 一张检查清单

动画只用 transform / opacity
不在循环里混用读写 DOM
长列表用虚拟滚动，而不是 display: none 隐藏
图片给足 width / height，避免布局抖动（CLS）
离屏内容用 content-visibility: auto 跳过渲染

渲染没有魔法，只有阶段与代价。把这两件事记住，性能问题就变成了一道可以算的题。

用 CSS Cascade Layers 收拾一个失控的样式表

Mon, 05 Oct 2026 02:17:00 +0000

一个项目跑了两年之后，样式表通常会长成三种东西的混合物：组件样式、工具类，以及一堆用来"压过别人"的补丁。

.page .card .card-body .btn.primary {
  background: #7c5cff !important;
}

写这行代码的人并不想这样，他只是没有别的办法。

# @layer 把优先级变成声明

@layer reset, base, components, utilities;

这一行的意思是：后声明的层永远赢，与选择器特异性无关。

于是 utilities 里的一个简单类：

@layer utilities {
  .mt-0 { margin-top: 0; }
}

可以稳定地压过 components 里那个写了五个类的复杂选择器：

@layer components {
  .page .card .card-body .title { margin-top: 24px; }
}

不需要 !important，也不需要提高特异性。层级关系是显式的，是可 review 的。

# 推荐的层结构

@layer reset,
       tokens,
       base,
       layout,
       components,
       utilities,
       overrides;

从低到高，语义清晰：

reset —— 抹平浏览器差异
tokens —— 设计变量，几乎不产生规则
base —— 元素默认样式
layout —— 栅格、容器
components —— 组件自己的一亩三分地
utilities —— 单职责工具类，永远能赢
overrides —— 临时补丁层，方便日后清理

# 和第三方库和平共处

这是 @layer 最实用的场景：把 UI 库整个塞进低优先级层。

@import url('vendor-ui.css') layer(vendor);

@layer vendor, components, utilities;

库里的 .button { padding: 8px 16px } 依然生效，但你的 .btn-lg 可以轻松覆盖它，不用再写 !important 对抗。

一个容易踩的坑：@import 必须写在所有规则之前。如果打包器把 CSS 拼接顺序打乱，层顺序可能不是你预期的——显式写一行 @layer a, b, c; 声明顺序最保险。

# 渐进增强的写法

老浏览器不认识 @layer，会直接忽略整条 at-rule 里的内容（而不是报错崩溃）。所以可以这样兜底：

/* 老浏览器走这条 */
.btn { padding: 10px 20px; }

/* 新浏览器用层来管理 */
@layer components {
  .btn { padding: 10px 20px; }
}

代价是重复一次声明，换来的是完全不依赖构建工具的兼容性。

# 迁移顺序建议

不要一次性重写。按这个顺序动，风险最小：

先加一行 @layer 声明，什么都不放
把 reset 和 tokens 搬进去
把工具类搬进 utilities，删掉对应的 !important
最后处理组件层，一边搬一边删掉为了压优先级而加的选择器

层叠不是敌人。它只是过去缺少一个可以表达"谁该赢"的语法。现在有了。

View Transitions：给多页应用加一点"原生感"

Mon, 28 Sep 2026 02:24:00 +0000

用户判断一个网站"快不快"，很大程度上取决于切换瞬间发生了什么。白屏 300ms 会让人觉得慢，哪怕实际加载只用了 200ms。

View Transitions API 解决的正是这个感知问题。

# 最小可用示例

async function navigate(url) {
  if (!document.startViewTransition) {
    location.href = url;
    return;
  }

  const res = await fetch(url);
  const html = await res.text();
  const doc = new DOMParser().parseFromString(html, 'text/html');

  document.startViewTransition(() => {
    document.body.replaceWith(doc.body);
  });
}

浏览器会自动做三件事：截取旧状态快照、执行你的 DOM 变更、截取新状态快照，然后在两张快照之间做交叉淡入。

# 给元素命名，才有共享元素动画

默认是整页淡入淡出。想让标题"飞"过去，需要 view-transition-name：

.post-title { view-transition-name: post-title; }
.post-cover { view-transition-name: post-cover; }

两个页面上同名，浏览器就会把它们当成同一个元素做位移动画。同一时刻页面上不能有两个同名元素，否则转场直接失效——这是最常见的翻车点。

# 三个容易翻车的细节

# 1. 滚动位置

转场期间页面被截图，滚动会被重置。记得恢复：

document.startViewTransition(() => {
  document.body.replaceWith(doc.body);
  window.scrollTo(0, 0);
});

# 2. 动画时长与可达性

::view-transition-old(root),
::view-transition-new(root) {
  animation-duration: 320ms;
}

@media (prefers-reduced-motion: reduce) {
  ::view-transition-group(*),
  ::view-transition-old(*),
  ::view-transition-new(*) {
    animation: none !important;
  }
}

前庭功能敏感的用户会因位移动画不适，这段媒体查询不是可选项。

# 3. 别让转场挡住交互

转场期间页面是"活的快照"，用户点击无效。如果 fetch 很慢，先请求再启动转场，不要先启动再等待：

// ✅ 数据就绪后再开始，转场只覆盖 DOM 替换那一瞬
const html = await fetchHtml(url);
document.startViewTransition(() => swap(html));

# MPA 版本：一行 CSS

如果站点是多页的，Chromium 已经支持跨文档转场：

@view-transition {
  navigation: auto;
}

加到两个页面的 CSS 里，站内跳转自动获得淡入效果。不支持的环境什么都不会发生，天然渐进增强。

体验优化最划算的地方，往往不是让事情变快，而是让等待变得可以被理解。

TypeScript 类型收窄：让编译器替你证明

Sat, 19 Sep 2026 02:31:00 +0000

写 TypeScript 三年之后，你会发现大部分 as 都是同一个原因：你比编译器更早知道了类型，但没有告诉它。

收窄（narrowing）就是告诉它的正确方式。

# 从最朴素的开始

type Result =
  | { ok: true; data: string }
  | { ok: false; error: Error };

function unwrap(r: Result) {
  if (r.ok) {
    return r.data;   // 这里 r 被收窄为 { ok: true; data: string }
  }
  throw r.error;     // 这里只剩 { ok: false; error: Error }
}

判别字段（discriminant）用字面量类型，是最高效的收窄方式。设计联合类型时，第一件事就是给它一个判别字段。

# 六种收窄手段

typeof —— 基础类型判断
instanceof —— 类实例
in —— 属性存在性
判别字段 —— 字面量联合
自定义类型守卫（x is T）
断言函数（asserts x is T）

自定义守卫值得多说一句：

function isUser(v: unknown): v is User {
  return (
    typeof v === 'object' && v !== null &&
    'id' in v && typeof (v as User).id === 'string'
  );
}

注意 返回值类型是 v is User 而不是 boolean。写成 boolean，调用处拿不到任何收窄，等于白写。

# never：让遗漏变成编译错误

type Shape =
  | { kind: 'circle'; r: number }
  | { kind: 'square'; size: number }
  | { kind: 'rect'; w: number; h: number };

function area(s: Shape): number {
  switch (s.kind) {
    case 'circle': return Math.PI * s.r ** 2;
    case 'square': return s.size ** 2;
    case 'rect':   return s.w * s.h;
    default:
      // 如果将来有人加了 'triangle' 却没改这里，
      // 下面这行会立刻报错，而不是静默返回 undefined
      const _exhaustive: never = s;
      throw new Error('Unhandled shape: ' + JSON.stringify(_exhaustive));
  }
}

这是类型系统里最便宜的一道回归测试。

# 一个真实的重构案例

改造前：

function render(data: any) {
  if (data.type === 'text') return renderText(data.value);
  if (data.type === 'image') return renderImage(data.url);
  return null;
}

改造后：

type Block =
  | { type: 'text'; value: string }
  | { type: 'image'; url: string; alt: string };

function render(block: Block): string {
  switch (block.type) {
    case 'text':  return renderText(block.value);
    case 'image': return renderImage(block.url, block.alt);
  }
}

调用处传错字段，编译期就会红。运行时 null 分支消失，?.和 as 也一起消失。

# 收窄的边界

收窄只在同一作用域、且值不可变时可靠。回调函数里的收窄会被编译器丢弃：

function handle(x: string | null) {
  if (!x) return;

  // ❌ 报错：回调可能在 x 被修改后执行
  setTimeout(() => console.log(x.trim()), 0);

  // ✅ 先存到常量
  const value = x;
  setTimeout(() => console.log(value.trim()), 0);
}

理解这一点，你就不会再写无意义的 !。

类型不是给编译器看的装饰，它是你写下的、可被机器验证的假设。

设计变量不是 CSS 变量换个名字

Tue, 08 Sep 2026 02:38:00 +0000

--color-primary 是最容易被滥用的变量名。它的问题不是不好用，而是它把决策和取值绑死了。

# 三层结构

一个能长期维护的 token 体系，通常有三层：

# 1. 原始值（primitive）

只描述"这是什么颜色"，不带语义。

--color-violet-500: #7c5cff;
--color-cyan-400: #22d3ee;
--color-slate-950: #0a0b10;

这一层不直接被组件使用。

# 2. 语义层（semantic）

描述"用在哪里"。

--surface-base: var(--color-slate-950);
--surface-raised: #12141c;
--text-primary: #eef1f8;
--text-muted: #98a2b8;
--accent: var(--color-violet-500);
--border-subtle: rgba(255,255,255,.08);

# 3. 组件层（component）

只在必要时存在，用来说明"这个组件怎么用语义 token"。

--card-bg: var(--surface-raised);
--card-border: var(--border-subtle);
--card-radius: 16px;

# 为什么不能只有一层

假设你只有 --color-primary。有三处需要"稍微淡一点的边框"，你怎么命名？

--color-primary-10？
--border-light？
--color-gray-800？

没有语义层，命名就会开始描述程度而不是用途，很快就没人知道该用哪个了。

而有了 --border-subtle，深浅调整只发生在一个地方。

# 暗色主题不是反色

换肤最常见的错误做法，是把所有颜色取反。结果通常是：纯黑背景 + 纯白文字，对比度过高，长时间阅读眼睛疼。

正确的做法是在语义层做映射：

:root {
  --surface-base: #f7f7f9;
  --text-primary: #14161c;
  --text-muted: #5b6472;
  --accent: #6d4aff;
}

[data-theme='dark'] {
  --surface-base: #0a0b10;   /* 不是 #000 */
  --text-primary: #eef1f8;   /* 不是 #fff */
  --text-muted: #98a2b8;
  --accent: #8b74ff;         /* 暗底上提亮，保证对比度 */
}

组件完全不感知主题，只引用语义 token。

# 增量落地

不要为了 token 化停下来两周做重构。可以这样切：

把现有硬编码颜色按出现频次排序，取前 20 个
为它们建立语义名，先在旧代码里引入变量但保持取值不变
新代码强制走 token，旧代码在改动时顺手迁移
加一条 lint 规则：组件 CSS 里出现十六进制颜色就警告

半年之后，你会发现换主题只需要改二十行。

性能预算：把"感觉慢"变成一条可以报警的红线

Sun, 30 Aug 2026 02:45:00 +0000

"这个页面有点慢" —— 这句话在评审会上没有杀伤力，因为它无法被反驳，也无法被验证。

性能预算的作用，是把它变成"LCP 超过 2.5s，构建失败"。

# 先定指标，再定阈值

三个核心指标，建议按这个优先级强制：

指标	含义	目标
LCP	最大内容绘制	< 2.5s
CLS	累积布局偏移	< 0.1
INP	交互到下次绘制	< 200ms

再加两个资源预算，兜住"悄悄变胖"：

首屏 JS gzip 后 < 180KB
首屏图片总量 < 500KB

# 用 Lighthouse CI 落地

npm i -D @lhci/cli

lighthouserc.json：

{
  "ci": {
    "collect": {
      "url": ["http://localhost:4173/", "http://localhost:4173/post.html?slug=css-layers"],
      "numberOfRuns": 3
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.9 }],
        "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
        "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }],
        "total-blocking-time": ["warn", { "maxNumericValue": 300 }]
      }
    },
    "upload": { "target": "temporary-public-storage" }
  }
}

跑三次取中位数，避免单次网络抖动造成误报。

# 在 CI 里卡住回归

- name: Build
  run: npm run build
- name: Performance budget
  run: npx lhci autorun

第一次接入建议先设成 warn，观察两周真实分布，再把稳定项升级成 error。一上来就 red，团队会习惯性跳过它。

# 三个立刻见效的动作

给图片加尺寸和懒加载——直接改善 CLS 与 LCP
首屏字体用 font-display: swap——避免文字闪烁
把非关键脚本改成 defer——减少主线程阻塞

性能预算真正的作用不是让分数变高，而是让"这次改动值不值得"变成一个有数字可对的讨论。

预算写进 CI 的那天，性能才从"有人在意"变成"项目属性"。