devgo.cn语法高亮又坏了。如果你维护过带代码块的博客，大概率对这句话不陌生。Prism、highlight.js、Shiki 这些代码高亮库都试过，每次换主题或升级依赖，总得重新折腾一遍。Dave Rupert 也受够了，于是他写了 microlighter——一个基于 CSS Custom Highlights API 的语法高亮工具。这个工具的思路很反直觉：高亮代码不一定要用 JavaScript 去改网页里的代码结构，用 CSS 就能搞定。
CSS Custom Highlights API 是浏览器提供的一种原生能力：你可以先用 JavaScript 把代码里的关键词、字符串、注释等片段标记为一个个“高亮范围”，然后完全交给 CSS 去决定这些范围长什么样。整个过程不修改 DOM（文档对象模型，浏览器把网页内容表示成树结构，JavaScript 通过它操作页面）里的代码文本，没有额外的 span 标签，没有转义问题。microlighter 正是围绕这个 API 设计的。
一位开发者看到 Dave 发布的当天就动手了：给自己的博客写了一个集成 PR（Pull Request，代码合并请求），把原来的 highlight.js 依赖和相关管道全部移除，只在匹配文章路径（比如 `/年份/文章别名`）且页面里有代码的情况下，从 CDN（内容分发网络，把静态资源放到离用户近的服务器上，加快加载）拉取 microlighter 并运行。
这是 microlighter 网站的截图，左侧就是网页代码示例，可以看到它展示的就是真实的代码文本。
这个 PR 没有立刻合并。这位开发者故意让它搁置了几天，让潜意识去判断“我到底是不是真的认可这个方案”。几天后仍然觉得好，才合并。这种谨慎其实很实在：换语法高亮方案是个低频但烦人的操作，一时冲动换过去，过几天可能又后悔。
Dave 在播客里解释过做这个工具的动机：“博客的语法高亮又坏了，得修。唉。Prism 做过、highlight.js 做过、Shiki 也做过。这次能不能用一种更省事的方式？” 他不是要否定所有现有工具，只是想要一个适合自己的方案。microlighter 的取舍也来自这种个人需求：把语法高亮从“内容转换 + 样式”变成纯粹的“样式操作”。代码在网站里是什么样，在 DOM 里就是什么样，不需要在内容层做任何转换。
这个思路对普通开发者有什么实际价值？如果你维护静态博客、文档站，或者任何需要展示代码的页面，microlighter 提供了一种更干净的架构：高亮逻辑与内容解耦，主题样式可以纯 CSS 控制，代码块在 DOM 中保持可读、可复制、可被浏览器原生查找。相比传统工具，它少了一层 DOM 操作，也少了很多因为嵌套 span 带来的麻烦。
当然，这个方案也有 trade-offs（权衡取舍）。CSS Custom Highlights API 的浏览器支持范围还不像传统方案那么全面，microlighter 的定位也是“够用就好”，功能上可能不如 highlight.js 或 Shiki 那样开箱即用、覆盖所有语言。如果你需要非常复杂的词法分析（把代码拆解成关键词、标识符等）或大量语言支持，可能还是得用重型方案。但如果你和 Dave 一样，只是想让博客代码高亮别再三天两头出问题，这个“用 CSS 解决样式问题”的思路值得一试。
最让人兴奋的是，浏览器正在提供越来越多以前做不到的能力。看到 CSS Custom Highlights API 这样的原生特性落地，并且有人做出 microlighter 这样的工具，会让人觉得 Web 平台还在往前走。
内容与图片版权归原作者所有 · 原文: https://blog.jim-nielsen.com/2026/shipping-microlighter/