{ "version": "https://jsonfeed.org/version/1", "title": "星舞互娱", "subtitle": "深夜编码手记", "icon": "https://xwhy.online/assets/favicon.ico", "description": "在终端与夜色之间，记录构建互联网的每一个细节：前端工程、性能优化与界面设计。", "home_page_url": "https://xwhy.online", "items": [ { "id": "https://xwhy.online/2026/10/12/rendering-pipeline/", "url": "https://xwhy.online/2026/10/12/rendering-pipeline/", "title": "把一帧画面拆开看：浏览器渲染流水线完全指南", "date_published": "2026-10-12T02:10:00.000Z", "content_html": "

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

\n

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

\n

# 五个阶段，一条流水线

\n

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

\n

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

\n

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

\n

# 三种改动，三种代价

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

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

\n

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

\n

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

\n

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

\n

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

\n

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

\n

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

\n

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

\n

修法很简单：先读后写。

\n

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

\n

# 怎么用 DevTools 抓到真凶

\n

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

\n

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

\n

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

\n

# 一张检查清单

\n

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

\n

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

\n", "tags": [ "浏览器原理", "性能优化", "渲染", "DevTools" ] }, { "id": "https://xwhy.online/2026/10/05/css-layers/", "url": "https://xwhy.online/2026/10/05/css-layers/", "title": "用 CSS Cascade Layers 收拾一个失控的样式表", "date_published": "2026-10-05T02:17:00.000Z", "content_html": "

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

\n

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

\n

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

\n

# @layer 把优先级变成声明

\n

@layer reset, base, components, utilities;

\n

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

\n

于是 utilities 里的一个简单类：

\n

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

\n

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

\n

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

\n

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

\n

# 推荐的层结构

\n

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

\n

从低到高，语义清晰：

\n

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

\n

# 和第三方库和平共处

\n

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

\n

@import url('vendor-ui.css') layer(vendor);\n\n@layer vendor, components, utilities;

\n

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

\n

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

\n

# 渐进增强的写法

\n

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

\n

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

\n

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

\n

# 迁移顺序建议

\n

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

\n

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

\n

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

\n", "tags": [ "CSS", "CSS", "架构", "可维护性" ] }, { "id": "https://xwhy.online/2026/09/28/view-transitions/", "url": "https://xwhy.online/2026/09/28/view-transitions/", "title": "View Transitions：给多页应用加一点\"原生感\"", "date_published": "2026-09-28T02:24:00.000Z", "content_html": "

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

\n

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

\n

# 最小可用示例

\n

async function navigate(url) {\n  if (!document.startViewTransition) {\n    location.href = url;\n    return;\n  }\n\n  const res = await fetch(url);\n  const html = await res.text();\n  const doc = new DOMParser().parseFromString(html, 'text/html');\n\n  document.startViewTransition(() => {\n    document.body.replaceWith(doc.body);\n  });\n}

\n

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

\n

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

\n

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

\n

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

\n

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

\n

# 三个容易翻车的细节

\n

# 1. 滚动位置

\n

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

\n

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

\n

# 2. 动画时长与可达性

\n

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

\n

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

\n

# 3. 别让转场挡住交互

\n

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

\n

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

\n

# MPA 版本：一行 CSS

\n

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

\n

@view-transition {\n  navigation: auto;\n}

\n

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

\n

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

\n", "tags": [ "交互体验", "动画", "API", "渐进增强" ] }, { "id": "https://xwhy.online/2026/09/19/typescript-narrowing/", "url": "https://xwhy.online/2026/09/19/typescript-narrowing/", "title": "TypeScript 类型收窄：让编译器替你证明", "date_published": "2026-09-19T02:31:00.000Z", "content_html": "

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

\n

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

\n

# 从最朴素的开始

\n

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

\n

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

\n

# 六种收窄手段

\n

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

\n

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

\n

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

\n

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

\n

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

\n

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

\n

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

\n

# 一个真实的重构案例

\n

改造前：

\n

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

\n

改造后：

\n

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

\n

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

\n

# 收窄的边界

\n

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

\n

function handle(x: string | null) {\n  if (!x) return;\n\n  // ❌ 报错：回调可能在 x 被修改后执行\n  setTimeout(() => console.log(x.trim()), 0);\n\n  // ✅ 先存到常量\n  const value = x;\n  setTimeout(() => console.log(value.trim()), 0);\n}

\n

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

\n

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

\n", "tags": [ "TypeScript", "TypeScript", "类型系统", "工程化" ] }, { "id": "https://xwhy.online/2026/09/08/design-tokens/", "url": "https://xwhy.online/2026/09/08/design-tokens/", "title": "设计变量不是 CSS 变量换个名字", "date_published": "2026-09-08T02:38:00.000Z", "content_html": "

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

\n

# 三层结构

\n

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

\n

# 1. 原始值（primitive）

\n

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

\n

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

\n

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

\n

# 2. 语义层（semantic）

\n

描述"用在哪里"。

\n

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

\n

# 3. 组件层（component）

\n

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

\n

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

\n

# 为什么不能只有一层

\n

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

\n

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

\n

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

\n

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

\n

# 暗色主题不是反色

\n

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

\n

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

\n

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

\n

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

\n

# 增量落地

\n

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

\n

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

\n

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

\n", "tags": [ "设计工程", "CSS", "架构", "设计系统" ] }, { "id": "https://xwhy.online/2026/08/30/web-performance-budget/", "url": "https://xwhy.online/2026/08/30/web-performance-budget/", "title": "性能预算：把\"感觉慢\"变成一条可以报警的红线", "date_published": "2026-08-30T02:45:00.000Z", "content_html": "

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

\n

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

\n

# 先定指标，再定阈值

\n

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

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

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

\n

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

\n

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

\n

# 用 Lighthouse CI 落地

\n

npm i -D @lhci/cli

\n

lighthouserc.json：

\n

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

\n

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

\n

# 在 CI 里卡住回归

\n

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

\n

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

\n

# 三个立刻见效的动作

\n

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

\n

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

\n

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

\n", "tags": [ "性能优化", "性能优化", "工程化", "CI/CD" ] } ] }