开发者依然常常困惑：既然运行时是单线程的，为什么不会卡死？ 为什么 setTimeout(0) 会“晚”触发？Promise、process.nextTick 和 setImmediate 究竟落在哪

前端周刊：系统性追踪海外一手前端动态，用地道的技术语言为中文开发者重构内容～

💬 扫码进群 | 🌍 海外情报源清单 | 🐱Github

💬 推荐语： 上周的前端圈子挺有意思：Vite 悄悄成为默认工具，Chrome 庆祝 17 岁生日，前端历史与未来的对比很耐人寻味。GSAP 动效依旧带来灵感，CSS 新特性也层出不穷，React/Svelte/Angular 等框架都在更新，生态热闹而多元。

🗂 本期精选目录

Web 开发

🔹《轻松实现函数式自定义元素》：用更轻松的方法实现函数式自定义元素。 推荐指数：⭐⭐⭐

🔹《让 XML 更易读，而不是靠 XSLT》：不依赖 XSLT，让 XML 变得更易读。 推荐指数：⭐⭐⭐

🔹《Vite 的静默崛起：对你的技术栈意味着什么》：Vite 静悄悄成为主流，对前端技术栈意味着什么。 推荐指数：⭐⭐⭐⭐

🔹《Chrome 17 岁了：一部浏览器的历史》：Chrome 浏览器 17 周年，一部发展史回顾。 推荐指数：⭐⭐⭐⭐

🔹《黑客未来：前端篇》：探索前端未来趋势的黑客式思考。 推荐指数：⭐⭐⭐

🔹《Nx 调查揭示 GitHub Actions 漏洞：npm Token 被盗，转向 Trusted Publishing》：Nx 团队调查发现 GitHub Actions 漏洞导致 npm token 被盗，推动转向 Trusted Publishing。 推荐指数：⭐⭐⭐⭐

🔹《前端学习笔记：安装 npm 包与打包》：前端学习笔记：安装 npm 包与打包基础。 推荐指数：⭐⭐⭐

---

性能 Performance

🔹《Node.js 在 2025 年如何榨干 I/O 性能》：Node.js 在 2025 年如何榨干 I/O 性能潜力。 推荐指数：⭐⭐⭐⭐

🔹《是否该预加载字体以提升性能？》：是否需要预加载字体来提升性能。 推荐指数：⭐⭐⭐

---

特效 Effects

🔹《用 GSAP 重现 Palmer 的可拖拽商品网格》：用 GSAP 重现 Palmer 的可拖拽商品网格。 推荐指数：⭐⭐⭐⭐

🔹《GSAP 开发者必知的 7 个动画技巧》：GSAP 开发者必知的 7 个动画技巧。 推荐指数：⭐⭐⭐⭐⭐

---

CSS

🔹《关键帧偏移详解》：深入理解关键帧偏移的用法。 推荐指数：⭐⭐⭐

🔹《CSS 对齐基础》：CSS 对齐基础知识梳理。 推荐指数：⭐⭐⭐⭐

🔹《你需要知道的 CSS 颜色插值》：关于 CSS 颜色插值你需要了解的点。 推荐指数：⭐⭐⭐⭐

🔹《纯 CSS 时间进度条：支持 Markdown / GitHub Pages》：纯 CSS 实现的时间进度条，适合在 markdown / GitHub Pages 使用。 推荐指数：⭐⭐⭐

🔹《light-dark() 函数是否应该支持更多模式？》：探讨 light-dark() 是否应支持更多模式。 推荐指数：⭐⭐⭐

🔹《CSS 颜色混乱实验》：一次关于 CSS 颜色的混乱探索。 推荐指数：⭐⭐⭐

---

JavaScript

🔹《为什么浏览器会限制 JavaScript 定时器？》：为什么浏览器要限制 JS 定时器的精度。 推荐指数：⭐⭐⭐⭐

🔹《用 Intl.Segmenter 精准计算文本长度》：用 Intl.Segmenter 精准计算文本长度。 推荐指数：⭐⭐⭐

🔹《JavaScript 开发者的精益思维》：JavaScript 开发者的精益思维。 推荐指数：⭐⭐⭐⭐

🔹《Svelte 2025 年 9 月更新》：Svelte 2025 年 9 月更新。 推荐指数：⭐⭐⭐

🔹《Angular 2025 夏季更新》：Angular 2025 夏季更新。 推荐指数：⭐⭐⭐

🔹《100 行 JavaScript 写扫雷》：用 100 行 JS 写扫雷游戏。 推荐指数：⭐⭐⭐⭐

---

React

🔹《用 Vite 构建 SSR：自定义替代 getStaticProps》：用 Vite 构建 SSR，自定义替代 getStaticProps。 推荐指数：⭐⭐⭐⭐

🔹《从服务端状态派生客户端状态》：探索如何从服务端状态推导出客户端状态。 推荐指数：⭐⭐⭐⭐

🔹《React 组件样式终极指南》：React 组件样式终极指南。 推荐指数：⭐⭐⭐⭐

🔹《用 React + Fluent-State 构建实时状态管理》：借助 Fluent-State 实现 React 的实时状态管理。 推荐指数：⭐⭐⭐⭐

---

本篇依然来自于我们的 《前端周刊》 项目！

由团队成员 掘金安东尼 翻译，欢迎大家 进群 持续追踪全球最新前端资讯!!

原文：jakub.kr/components/…

OKLCH 是一种较新的颜色模型，设计目标是感知均匀（perceptually uniform） 。换句话说，它能够更贴近人类视觉的感受来表示颜色，让我们在使用和调整颜色时更加顺手、直观。

颜色模型

在理解 OKLCH 与其他颜色模型的区别之前，我们需要先弄清一些基本概念。

颜色模型就是一种“描述颜色的系统”。常见的有 RGB、HSL、LCH、OKLCH 等。不同模型决定了颜色能否容易地被理解、操作和思考。

---

色域（Gamut）

色域就像是一个“活动范围”，定义了某个模型下能表现的所有颜色。常见的色域有：

• sRGB —— 网页默认色域
• Display-P3 —— 现代设备常用的广色域

色域对比示意图（CIE 1931 xy 色度图）：

需要注意的是，颜色空间不仅仅定义色域，还包括白点、传递函数等更多参数。为了简化，这里就不展开了。

---

结构（Structure）

和 LCH 类似，OKLCH 由三个值组成：

• Lightness（亮度） ：控制明暗，范围 0–1 或 0%–100%。
• Chroma（彩度） ：控制颜色的强度，类似饱和度。
• Hue（色相） ：控制色调，范围 0–360°。

区别在于：OKLCH 基于 OKLab 颜色空间，而 LCH 基于 CIELAB。

---

一致的亮度（Consistent Brightness）

假设你想设计几个不同颜色的按钮。传统模型（如 HSL）通常需要一个个手动调整才能看起来协调。

而在 OKLCH 中，你只需要保持 相同的亮度和彩度，只改色相，就能生成一组感知上一致的颜色。

相比之下，用 HSL 做同样的事，结果往往不均匀：有的太亮、有的太暗、有的颜色跳出来、有的又显得沉闷。

这正是 OKLCH 的最大优势之一 —— 轻松创建感知均匀的调色板。

---

可预测的明暗变化（Predictable Shades）

如果只调整亮度，OKLCH 可以生成一系列有条理的色阶，而不会像 HSL 那样发生色相漂移。

OKLCH 与 HSL 的色阶对比：

在 HSL 中，浅蓝会飘向紫色，深蓝则会发灰。OKLCH 则始终保持“蓝色”感。

---

渐变（Gradients）

OKLCH 渐变的生成逻辑与传统不同。传统渐变是基于 RGB 通道计算的，常常会出现暗沉的中点或亮度不均的问题。

sRGB / OKLab / OKLCH 渐变对比图：

在 OKLCH 中，渐变的计算基于亮度、彩度和色相，因此过渡更自然。但这也带来一个副作用：渐变可能出现你没定义过的中间颜色，因为色相是一个环形参数，路径可能绕弯。

为避免这种情况，许多工具选择用 OKLab 来生成渐变，它的插值更线性，更稳定。

---

色域支持（Color Space Support）

sRGB 色域的限制在于，它无法覆盖现代屏幕能显示的全部颜色。而 OKLCH 可以直接书写 Display-P3 色域的颜色。

sRGB 与 Display-P3 对比：

• 如果你的设备支持 Display-P3，你会看到右边的颜色比左边更鲜艳。
• 如果设备只支持 sRGB，浏览器会把超出部分映射回 sRGB，显示结果接近。

灰色在两者中没有区别。

---

最大彩度（Maximum Chroma）

OKLCH 理论上可以定义超出任何现实屏幕的颜色。

例如：

oklch(0.7 0.4 40)

这个颜色彩度极高，数学上成立，但所有实际显示器都无法完整呈现。它会被“裁剪”或映射到最接近的可显示颜色。

因此，我们需要一个“最大彩度”的概念：它会根据亮度、色相和色域，计算出设备所能显示的极限值。

---

浏览器支持与回退方案

OKLCH 定义在 CSS Color Module Level 4 中，目前大多数现代浏览器都支持。

但在一些老旧浏览器中可能不兼容。这时，可以通过 @supports 添加回退方案：

@layer base {
  :root {
    /* sRGB 颜色 */
    --color-gray-100: #fcfcfc;

    @supports (color: oklch(0 0 0)) {
      /* OKLCH 颜色 */
      --color-gray-100: oklch(0.991 0 0);
    }
  }
}

如果浏览器支持，就用 OKLCH；不支持，就用 sRGB。

---

工具：oklch.fyi

我还做了一个小工具 oklch.fyi，可以：

• 生成 OKLCH 调色板
• 把你现有的 CSS 变量转换为 OKLCH
• 帮助更直观地探索这个模型

---

小结

点评：以前的颜色模型像是老旧的地铁地图，表面上线路对齐，但实际走起来，有的站很近、有的很远，比例不准，导致颜色数值改一点，肉眼感觉却差很多。

OKLCH 就像是按真实比例绘制的导航地图，每一步都和人眼的感受匹配：亮度就是亮度，色相就是色相，不会跑偏。

背后技术就是 OKLab 感知均匀色彩空间，它用数学方法模拟人眼对颜色的敏感度，修正了老模型的不均匀性。