我今天的第一篇文章《被微信蹭热点了吗？关于深色模式的碎碎念》谈了我对深色模式整体的想法，下面来说说我是怎么给我的博客适配深色模式的。
它是用Jekyll生成的静态网站，托管在GitHub上。但适配深色模式主要是改CSS，所以其他形式的网站也一样可以借鉴。
技术层面，我主要参考的是WebKit团队去年的一篇博文《WebKit对深色模式的支持》（Dark Mode Support in WebKit）。
但我的主要纠结主要在于配色。
对一个疑似完美主义者，如果不确定一套方法论，而是直接选颜色，会进入无止尽的纠结。
所以在一番探索和尝试后，我订下了三条原则，将需要的选择和纠结降到了最低。
其一，默认模式与之前基本保持不变。
我知道很多人和我一样还没准备好接受深色，所以如果用户的系统没有设成深色，默认的还是人见人爱的浅色。
适配深色的过程中，我总有冲动把浅色版本的配色改得“更配套”。但想到博客最初搭建的时候，选色经历了同样一番纠结，才稳定到现在我认为最舒适的版本，所以尽量不改。
其二，配色参考微信公众号和Safari阅读器视图。
其实，当时最初浅色版本的配色和排版也参考了公众号的默认效果（比如正文的颜色其实是深灰而非纯黑）。
所以当我看到公众号的深色模式挺舒服，就选择继续相信微信设计师的水平。
当然，让我的博客和公众号长得几乎一模一样，也有助于降低碎片化，保持“品牌”的统一，方便读者在不同平台间的跳转。
有人会说了，微信今天才支持的深色模式，你上周是怎么参考的？
其实，公众号的网页版（就是从浏览器打开公众号文章）已经支持深色模式有一段时间了。这甚至就是我想让我的博客也适配的最初动力。
从电脑的浏览器打开公众号文章，用开发者工具选择要查看的元素，你不但能看到颜色的选择，还能看到微信的前端工程师是怎么写CSS的。
出于同样的道理，除了公众号的网页版，我也参考了Safari的阅读器视图。
话说，参考配色，应该不犯法吧？
其三，统一相近的颜色，减少需要的选择。
以前看到过一个帖子说，如果仔细看，能发现某国民App（好像还是微信？）同一个页面用了好多种不同的灰色，不同的字号。
为了不犯同样的错误，我总结了我的网站需要的颜色，一直压缩到六种。
- 主内容色，比如正文。
- 副内容色，比如附注、引用，就是文章中灰色的文字。除了文章，网站中的其他零零碎碎的部分也都用的是这。
- 背景色。
- 副背景色，比如代码块、评论区的底色，引用部分左边的竖线。
- 超链接。
- 品牌色，就是网站的名称“青菜年糕汤”和标志的颜色。
这样，我定义了六个颜色变量名，给它们设好两套颜色，就不用对各个元素的分别硬编码了。
更重要的是，我可以尽量减少在256度灰中纠结的时间了：我只用选两套各四种灰色，而不是两套各无数种元素的颜色。
这三条原则几乎解决了所有适配的问题，除了一个：
我博客的上有一个大大的微信公众号二维码，不透明白底黑字，还带绿色的标志。深色模式下显得很突兀。
我觉得最合适的方案是把它变成矢量图（如SVG），然后就能用上前面定义的两套颜色。但这样做的的时间成本太高。
最后选择的方案是加了个滤镜：先做反色（但不能100%反色，因为我的深色模式的背景不是纯黑，需要仔细调整），再180度翻转色调（hue-rotate），避免反色把标志性的绿色变成奇怪的颜色。
然后我把同样的滤镜加到了我的更文进度的可视化上，轻松获得了不错的效果。
对于这种没有明确定义的问题，解决肉眼可见的问题只是第一步。在之后的使用过程中必然有更多细碎的细节问题需要修正，会有长尾效应。
在正式的工程实践中，一般会有内部工程师的各种手动和自动化的Alpha测试，也会有在公开发布前小规模用户的Beta测试。
但据我所知，我的网站的常客只有我自己，所以看着没问题就发布了。倒是有点“Move fast and break things”（快速行动，打破东西？）的风范。
后面的两天，我分别在电脑（Safari和Chrome）和手机（Safari）上随机翻阅我的网站。
我陆陆续续发现了一些没有适配好的细节，比如加粗、引用、代码块、公式的问题，再比如不同浏览器滤镜的色差。
修正了这些问题，总算是大功告成。
如果你也打算给你的网站适配深色模式，如果有想探讨的问题，欢迎在墙外访问本页面拖到最下面评论，或在公众号里给我发消息。