CC Switch 在 Windows 上启动闪白屏怎么办

2026-08-31

桌面应用启动时先闪一下白、再翻成深色，这类现象很容易被归到「电脑慢」「显卡驱动」上，然后就没有下文了。但它其实有一条很确定的因果链：窗口先被显示出来，页面还没画完；或者页面画完了，但决定深色浅色的那段逻辑跑在了首帧之后。两者都会让用户看到一帧「不属于这个应用」的画面。

CC Switch 这个项目在 v3.20.0 修过这个问题，修法值得单独拆一次——因为它不是「加个延时」了事，而是同时动了前端入口 HTML、Tauri 的安全策略、以及 Rust 侧的窗口显示时机三个地方，三处缺一不可。

本文依据什么

下面所有说法都来自 farion1231/cc-switch 仓库的一份本地快照：commit 3217f725，仓库内版本号 3.20.1，核对日 2026-08-31。我们只做静态阅读——读源码、读 docs/ 下的发布说明、读 commit 与 diff，没有编译、没有运行、也没有安装过这个桌面应用。所以本文不会出现任何关于界面长什么样、切换有多快的描述；凡是涉及现象的部分，都会标明它来自仓库里的哪一份文档或哪一条提交记录。

先确认你碰到的是不是这一类

排查的第一步不是改配置，而是把「这个版本里到底有没有这套修复」确认下来。修复对应的提交是 d4fefefc，标题 fix(windows): eliminate startup white-black flash (FOUC) (#6252)，commit body 里写了 Fixes #6182，随 v3.20.0 发布。三处改动都可以逐一比对，动作很具体：

第一处，看 src/index.html 的第 7 行有没有一段内联脚本。 v3.20.1 里这一行是：

<script>(function(){try{var t=localStorage.getItem("cc-switch-theme")||"system";var d=t==="dark"||(t==="system"&&matchMedia("(prefers-color-scheme: dark)").matches);document.documentElement.classList.toggle("dark",d);}catch(e){}})()</script>

它在 bundle 加载之前同步读一次 localStorage 里的 cc-switch-theme（读不到时按 "system" 处理），据此决定要不要把 dark 类挂到 document.documentElement 上。整段包在 try{}catch(e){} 里——读存储失败不能把首屏卡住。

第二处，看 src-tauri/tauri.conf.json 第 29 行的 CSP。 v3.20.1 里 script-src 的值是 'self' 加上一串 'sha256-...'；如果你手上的版本这里只有 'self'，那么上面那段内联脚本就算写了也会被 CSP 拦掉。

第三处，看 src-tauri/src/lib.rs 有没有 Windows 专属的 on_page_load 分支。 v3.20.1 里，:392 声明了一个 AtomicBool（名字是 startup_page_handled），随后的闭包里四个条件同时满足才调 webview.window().show()：webview 的 label() 是 main、payload.event() 是 PageLoadEvent::Finished、payload.url().scheme() 不是 about、swap(true, Ordering::Relaxed) 返回 false（也就是首次），并且 crate::settings::get_settings().silent_startup 为假。

在 Windows 上三处都在，说明这套修复在你的代码里；三处缺任何一处，链路就断在那一环上。第三处是 Windows 专属的，其它平台看不到它属于正常，具体见下一节。

这三处各自堵住了哪一段

把它们拆开看，会发现堵的根本不是同一个漏洞。

Rust 侧堵的是「窗口比页面早」。 发布说明 docs/release-notes/v3.20.0-zh.md:165 对症状的表述是：窗口在主题类应用之前就被显示，未着色的页面先画了一帧。也就是说，窗口本身出现得太早。窗口在配置里本来就是隐藏起点——src-tauri/tauri.conf.json:22 写的是 "visible": false，Windows 侧的覆盖文件 src-tauri/tauri.windows.conf.json:9 同样是 false——真正决定何时 show() 的是 Rust。改动前，正常启动路径直接 window.show()；改动后，这条立即显示的分支被 #[cfg(not(target_os = "windows"))] 排除掉，Windows 上改成等主页面 Finished 再显示。src-tauri/src/lib.rs:1341 附近那段可以对照着读：silent_startup 为真时窗口保持隐藏，为假时非 Windows 平台走立即 show()，Windows 平台只打一行「等待主页面加载完成后显示主窗口」的日志。

那两个看起来多余的条件其实各有各的用处。scheme() != "about" 是为了不让空白的初始文档触发提前显示——about: 开头的那一帧正是我们想跳过的东西。AtomicBool 的 swap 保证整个进程只显示一次：页面之后若再重载，这个钩子不会二次触发 show()。

前端侧堵的是「首帧没带主题」。 就算窗口显示时机挪对了，如果决定深浅色的逻辑跟着 JS bundle 一起异步执行，首帧仍然可能是未着色的。内联脚本的价值就在「同步」两个字上：它在解析 <head> 时就跑完，dark 类在第一次绘制前已经挂好。

这两半的适用范围不一样。 非 Windows 平台维持原来的立即显示行为，只享受 index.html 这一半修复。所以如果你在别的平台上遇到类似现象，上面第三处的比对对你没有意义。

那串 sha256 是怎么来的，为什么不图省事

内联脚本在 CSP 下默认是被拒的。要放行有两条路：一条是给 script-src 加 'unsafe-inline'，一句话搞定，代价是全站所有内联脚本都被放行；另一条是给这一段脚本算一个摘要，只放行内容完全一致的那一段。这个项目选了后者。

摘要值可以自己算，算法就是对 <script> 标签内的脚本正文做 SHA-256 再 base64：

python3 -c "
import hashlib,base64,re
h=open('src/index.html','r',encoding='utf-8').read()
s=re.search(r'<script>(.*?)</script>',h,re.S).group(1)
print('sha256-'+base64.b64encode(hashlib.sha256(s.encode()).digest()).decode())
"

我们对 v3.20.1 的快照文件实算过一次，得到的结果与 tauri.conf.json:29 里写着的那串逐字符一致。这也是排查时最硬的一个动作：不需要猜，算一遍就知道两边对不对得上。

代价也很直白：这段脚本一个字符都不能动。改缩进、改引号、加个分号，摘要就变了，而 tauri.conf.json 里那串没跟着改的话，脚本会被 CSP 拦掉——不报错、不崩溃，只是主题类没挂上，闪屏回归。同理，如果你在自己的构建管线里插了会改写 HTML 的步骤（压缩、格式化、把内联脚本外提），也要重新核这个摘要。这条对二次开发的人尤其重要。

处置之后怎么验证

三个可执行的核对点，都不需要跑程序：

用上面那段命令重算摘要，和 tauri.conf.json:29 里的值逐字符比对。这一步同时验证了「脚本还在」和「哈希没过期」两件事。
确认构建产物里的 HTML 仍然保留那段内联脚本，且内容与源文件一致。tauri.conf.json:7 指定 frontendDist: "../dist"，Tauri 打包时用的是构建出来的那份，不是 src/ 下的原件。
确认 lib.rs 里那条 Windows 分支没有被后续改动绕过——尤其是有没有别的地方重新加回了无条件的 window.show()。这条钩子的语义是「唯一的首屏显示入口」，一旦有第二个入口，AtomicBool 就守不住了。

需要说清楚的是：以上都是源码层面的一致性检查，能确认修复的三处结构是否完整，不能证明实际运行时不会闪。渲染时序还受 WebView2 版本、系统主题、磁盘速度等一堆因素影响，源码检查只能排除「代码这边写漏了」这一类原因。

什么情况说明不是这个原因

这一节比上面几节都重要，因为它决定你要不要继续往这个方向查。

窗口干脆不出现，而不是闪一下。 这是另一回事。silent_startup 为真时窗口本来就保持隐藏（src-tauri/src/lib.rs:1341 的分支），而 Windows 上的显示又被绑在 PageLoadEvent::Finished 上——页面根本没加载完的话，窗口也就不会出现。这两种情况的表现是「没有窗口」，不是「先白后深」，不该往闪屏上归因。
你不在 Windows 上。 Rust 侧那半修复带 #[cfg(target_os = "windows")]，其它平台走的是另一条路径，比对它没有意义。
闪的不是首帧，而是使用过程中的某次重绘。 AtomicBool 只管首次显示，后续页面重载不再触发 show()；换句话说，这套机制从设计上就不覆盖启动之后的任何一次重绘。
主题偏好本身没被持久化。 内联脚本读的是 localStorage 里的 cc-switch-theme，读不到就按 "system" 走。如果存储里根本没有这个键，脚本会正常执行、只是按系统偏好判断——这属于「按预期工作」，不是缺陷。

顺带记一处对不上的地方

d4fefefc 这条提交的信息第一句提到了「把窗口 backgroundColor 设成与深色主题一致」。但在 v3.20.1 的快照里，grep -rn "backgroundColor" src-tauri/ --include=*.json --include=*.rs 是 0 命中，grep -rn "background_color" src-tauri/src 同样是 0 命中；这条提交实际落地的 diff 只有三样：on_page_load 的显示时机、CSP、以及 index.html 里那行内联脚本。

也就是说，提交信息描述的事情比合入的改动多一件。以我们实读的仓库状态为准：这个版本里没有窗口背景色设置。排查时别按「应该已经设过背景色了」这个前提往下推——说到这里就够了，我们不打算继续揣测这一件为什么没进去。

这条链路真正值钱的地方

抛开这个具体项目，「启动闪一下」这类问题的排查顺序其实是固定的三问：窗口是什么时候被显示的、决定外观的那段逻辑是什么时候执行的、这两者之间有没有强制的先后关系。CC Switch 的做法是把「显示」挂到页面加载完成事件上，把「着色」提前到 bundle 之前的同步脚本里，等于从两头把窗口收紧——但也因此多欠了一笔 CSP 的债，需要靠一个摘要值把内联脚本钉死。

工程上很少有不带代价的修法，能把代价说清楚的修法才好维护。

本文依据 CC Switch 官方仓库（github.com/farion1231/cc-switch）的 README、docs/ 下的用户手册、路由指南与发布说明，以及 src/、src-tauri/、tests/ 的源码整理，核对日 2026-08-31，对应仓库快照 3217f725（仓库内版本号 3.20.1）。本文内容为仓库源码与文档口径，我们没有安装或运行过这个桌面应用，因此不涉及界面外观、操作手感与切换速度的任何描述。文中出现的阈值与默认值均为源码中的默认配置，不构成对实际运行结果的保证。该项目仍在快速迭代，版本与默认值随时可能变动，请以仓库最新内容为准。安全相关做法请结合自身环境评估，本文不构成安全方案建议。

留言讨论

评论发布后会被人工复核，违规内容将被删除。

如果发表没有反应，可以前往联系我们告诉我们。