最安全方式是用 ，需同时满足HTML与CSS路径一致、主进程用loadFile加载、打包未写死绝对路径；相对路径不触发Chromium跨域拦截，因同项目树内属常规文件解析。
直接用 <link rel="stylesheet" href="./styles/main.css"> 是最安全、最省心的方式，前提是三个条件同时满足：HTML 和 CSS 物理路径关系与相对路径一致、主进程用 loadFile 加载、打包后没写死绝对路径。
为什么相对路径能绕过 Chromium 的安全拦截
Chromium 对 file:// 协议的限制主要针对跨目录请求（比如从 file:///app/index.html 去加载 file:///app/../styles/main.css），但对同项目树内的相对路径（./styles/main.css）是原生支持的——它不触发跨域或协议级拦截，只走常规文件解析流程。
常见翻车点：
-
index.html在dist/app/下，却写href="./styles/main.css"（实际应为../styles/main.css） - 主进程用了
win.loadURL('file://' + path.join(__dirname, 'dist', 'index.html'))，导致 Chromium 丢失当前目录上下文，相对路径失效 - CSS 文件里用了
@import './theme.css';—— 这个在 asar 打包后大概率静默失败，因为@import的路径解析由浏览器执行，不经过 Electron 的 asar 解包逻辑
preload.js 注入 CSS 字符串的实操要点
适合小量样式、主题切换或需运行时控制的场景，但不能替代主样式表。它绕过所有协议限制，因为内容是字符串，不是外部请求。
立即学习“前端免费学习笔记（深入）”；
关键操作：
- 确保
BrowserWindow配置中启用了preload，且contextIsolation: true - 路径必须用
path.join(__dirname, '../styles/main.css')，__dirname指的是preload.js所在目录，不是 HTML 所在目录 - 打包后要用
process.resourcesPath或app.getAppPath()替代__dirname，否则读不到 asar 内部文件 - 注入时机必须等
document.addEventListener('DOMContentLoaded', ...)，不能在 preload 脚本顶部就执行 - 大体积 CSS 推荐用
readFileSync(..., 'utf8').trim()清掉 BOM，避免解析失败
注册 app:// 协议是唯一可扩展的长期方案
当项目结构复杂、CSS 分布在多层目录、或需要复用同一套资源映射逻辑时，硬靠相对路径会越来越难维护。注册自定义协议让资源走 Chromium 明确允许的通道，语义清晰、兼容 asar、无 CSP 风险。
注册必须满足：
- 在
app.whenReady()之后、BrowserWindow创建之前调用protocol.registerFileProtocol('app', ...) - 回调里必须用
path.normalize()处理request.url.slice(6)拼出的路径，否则../../../etc/passwd可能逃逸出根目录 - HTML 中写
<link rel="stylesheet" href="app://css/main.css">，注意协议名和路径大小写要和注册时完全一致 - 开发时改了注册逻辑必须重启应用，Electron 不热重载 protocol 配置
最容易被忽略的一点：无论用哪种方式，只要涉及路径拼接（尤其是 path.join 或 path.normalize），Windows 下的反斜杠、空格、中文字符都必须被正确处理；file:// 协议本身不接受未编码的空格，而 app:// 和相对路径则天然规避这个问题。
