夜雨聆风
废话不多说，先看看效果吧👇
首页、文档编辑器、工具栏、菜单、评论区和分享面板都能跟随深色模式。
文件图标、品牌 Logo、头像、文档填充色和图表颜色，则尽量保留原样。
它还支持四种切换方式：
日落到日出 跟随系统 始终深色 自定义时段
默认推荐“日落到日出”。插件会自动识别设备时区，根据参考位置估算当天的日出、日落时间。太阳落下后自动变深，日出后恢复。
如果希望时间更准确，也可以主动授权精确位置。相关信息只保存在本机，不依赖第三方天气和地图服务。
现在看起来，它只是一套安静工作的深色模式。
但这套“安静”，可被折腾得一点都不安静 
为什么要做这个插件？
最初的需求特别朴素。
昨天晚上加班时，电脑明明已经进入深色模式，浏览器一打开金山文档，整块白色页面还是迎面砸过来。
人一下就精神了。
一直以来，WPS 官方都没有提供完整的 Web 深色模式，迟迟没等到。
昨晚睡觉前，我突然灵机一动：既然官方暂时没做，那就让和 WPS 师出同门的 Agent 产品「灵犀」，帮我先做一个 Chrome 插件。属于魔法打败魔法了...
我本来觉得这应该不复杂，无非是把白色变黑、黑色变白，再配一个开关。
第二天一早，我正式打开插件，开始了一整天零碎的体验、截图和返工。
然后才发现：如果深色模式只是反色，那医院拍 X 光也算完成了 UI 适配。
深色模式不该让我每天手动上班
在具体折腾颜色之前，我先想了一个普通用户更容易遇到的问题：深色模式到底应该什么时候开启？
最简单的方案，是放一个开关。晚上自己打开，白天自己关闭。
但我做这个插件，本来就是不想折腾。结果为了少看一块白色页面，每天还得记得给插件上下班，多少有点本末倒置。 另一个办法，是写死时间。比如晚上 7 点开启，早上 7 点关闭。
听起来合理，但夏天晚上 7 点天可能还亮着，冬天下午 5 点窗外已经黑了。出差换个时区，固定时间也会立刻失去参考价值。
所以我最后把“日落到日出”设成了推荐模式。插件自动识别时区，根据日出日落切换外观。大多数时候，用户根本不需要打开设置页。
但自动化也不能替所有人做决定。有人希望网页跟随电脑的系统外观；有人长期在暗室工作，只想始终深色；也有人作息特殊，需要自己规定时间。
所以“跟随系统”“始终深色”和“自定义时段”也都保留了。 这四种模式不是为了把设置页做得丰富。它们只是在承认：所谓智能，不可能永远猜对。
默认模式替大多数人省事，其他模式给剩下的人留出口。 自动化可以帮用户做决定，但不能拿走用户自己决定的权利。
第一版确实变黑了，也确实不能用
说回来，第一版插件的实现方式非常直接。给整个网页套一层颜色反转。
一行 invert 下去，页面当场变黑。
开发进度看起来已经完成了 80%，剩下的 80%则负责证明前面的 80%为什么不对。
首页左侧还是白的，文件列表已经黑了；工具栏黑了，弹出的菜单又是白的；有些按钮像从日间模式里临时借过来的，特别显眼（没眼看...
更精彩的是图标。
文件图标、WPS 产品图标、用户头像，全被一起反转。绿色变成奇怪的紫色，红色文件图标换了色相，真人头像则直接进入底片模式。
这时候才明白，深色模式的第一个难点根本不是“怎么变黑”。
而是：哪些东西应该变，哪些东西绝对不能变。
图标不能变，文档内容更不能乱变
界面背景和普通文字可以适配深色。
但头像、品牌 Logo、文件类型图标，本来就有自己的颜色。它们不是界面底色，不该跟着一起翻面。
文档里的内容更麻烦。
用户在表格中设置的深蓝色表头、红色数字、绿色链接、单元格填充和图表颜色，属于文档本身。插件如果擅自改掉，看的就已经不是同一份文件了。
日间模式里是深蓝色表头，到了晚上变成浅蓝色，这不能叫护眼。这叫插件重新设计了一遍文档吧。
后来参考 Apple 深色模式的处理逻辑，把页面拆成了两类元素：
界面中的中性色跟随深色外观 头像、图片、品牌图标和作者设置的彩色内容尽量保留原值。
听起来只是一句话，落到金山文档里却不轻松。
因为有些图标是图片，有些是 SVG，有些藏在 CSS 背景里；有些表格是 DOM，有些正文和图表直接画在 Canvas 上。
它们看起来都叫“一个图标”或者“一张表格”，浏览器看到的却完全不是一回事。
菜单也是一场“套娃”
首页适配完，并不代表文档页面适配完。
文字、表格、智能文档、PDF，有各自的工具栏、侧栏、评论区和状态栏。点击按钮后，还会临时创建菜单、气泡、分享面板和账户卡片。
其中最典型的是分享面板:
外层弹窗反转一次，里面的卡片又反转一次。两层效果互相抵消，最后得到一张接近白色的卡片，配上接近白色的文字。
很有设计感。
属于信息和背景成功融为一体，谁也别想看见谁。
菜单阴影也会跟着反转。日间模式里的黑色阴影，到了深色模式下变成一圈白色光晕。每个弹窗都像刚从仙界下凡......
后面的处理原则变得很明确：一个弹层只能经过一次场景转换。里面的主按钮、开关、头像和分享渠道图标，再根据自身属性单独保留原色。
不追求把每个组件重新设计一遍，只让金山文档原来的层级关系在深色环境里继续成立。
这才开始接近“原生”。
最严重的问题不是颜色，是页面直接卡死
做到中间，有一次页面不再只是难看了。
它直接失去响应。
为了尽可能保留表格和文档颜色，早期方案使用了多阶段 SVG 滤镜，还会持续观察页面变化，扫描后来出现的元素。
小页面还能撑住。
一旦打开大型表格，浏览器需要反复处理整块画布，再叠加金山文档本身的编辑、滚动、协作和渲染任务，主线程很快就开始喘不过气。
最后 Chrome 弹出“页面无响应”。
这一下把问题说得很清楚。
一个深色模式插件，如果让办公文档卡死，那它最大的护眼功能，就是劝用户别打开文档。
从 2.6.0 开始，插件基本重写了性能方案。
大型表格不再经过复杂的逐像素 SVG 管线，改用 Chrome 原生合成能力；动态颜色检查放到浏览器空闲时分批执行；不再监听高频变化的 style、fill 和 stroke 属性；内容脚本只在顶层页面运行，避免多个内嵌页面重复启动。
现在每批最多检查 400 个元素，待处理队列最多保留 64 个根节点，普通定时回退单次占用不超过 8 毫秒。
翻译一下：宁可晚一点保护某个小图标，也不能为了找一个图标，把整张表格拖死。
深色模式首先得让页面活着。
解决了卡死，又来了白闪
性能稳住以后，还有一个特别影响体验的问题。
从首页点击文档，新标签页会先出现一整块白色，然后工具栏、侧栏、画布陆续变黑。
颜色最后是对的。
但打开过程像装修直播：先展示毛坯房，再当着用户的面一块块刷墙。
这个问题不能靠多写几条颜色规则解决，因为错误发生在页面开始渲染的前几帧。
最终的处理方式，是让插件在 document_start 阶段介入。
新页面最开始不展示尚未适配的正文，而是先显示统一的石墨灰启动底板。等工具栏、侧栏和文档画布完成第一轮创建，并短暂稳定后，再一次性显示完整页面。
同时设置最长等待时间。网络慢或者文档持续变化时，也不能一直停在启动底板。
实际从首页重新打开表格时，捕获到的第一帧已经是深色底板。随后出现的就是完整深色文档，不再经历那次刺眼的白闪。
这部分用户未必会注意到。
但不被注意，恰恰说明它做对了。
AI 能写代码，但它不知道哪里让人难受
这个插件的开发过程里，AI 写了很多代码，也能分析 DOM、修改 CSS、跑测试、重新打包，甚至接入 Chrome 检查真实页面。
但真正推动它从“页面变黑”走到“可以长期使用”的，并不是某一句神奇提示词。
而是一轮轮具体反馈：
这里头像反色了、那里菜单有白色光晕、表格颜色被改了、分享面板看不清、新页面会白闪、浏览器被拖死了。
这些反馈看起来很碎，却共同定义了一件事：什么叫真正可用。
AI 很擅长快速给出一个答案。人需要负责指出，这个答案到底哪里难受。
所以这个插件最后补的并不只是深色模式。它补的是颜色语义、内容边界、动态组件、浏览器合成、性能预算和启动体验。
我原本只是想让金山文档黑一点 
最后得到的最大教训却是：
好的深色模式，不是让用户看见你把页面变黑了，而是让用户忘记自己装过一个插件。
整个项目已打包上传 GitHub，欢迎大家下载体验：
https://github.com/Githun1314/kdocs-dark-mode
