最简可靠方案是用 win.loadFile() 加载 HTML 并保持相对路径，需满足：HTML 与 CSS 物理位置匹配、主进程调用 win.loadFile('src/index.html')、打包时避免硬编码绝对路径；其他方案如注册 app:// 协议或 preload 注入 CSS 各有适用场景与限制。
用 win.loadFile() 加载 HTML + 相对路径最简可靠
只要满足三个条件，./styles/main.css 就能直接用，不注册协议、不关安全策略、不写死路径。它走 Chromium 原生文件解析流程，不触发跨目录拦截。
- HTML 和 CSS 的物理位置必须与
href中路径完全对应（例如index.html在src/，CSS 在src/styles/main.css，就写./styles/main.css） - 主进程必须调用
win.loadFile('src/index.html')—— 用loadURL('file://...')会丢失当前目录上下文，相对路径立刻失效 - 打包进
.asar后仍有效，前提是路径没硬编码成绝对路径；Electron 运行时自动解包并映射相对路径
常见翻车点：@import './theme.css' 在 .asar 中静默失败，因为浏览器无法解析 asar 内部路径；CSS 文件里嵌套引用不如扁平化合并或改用 JS 动态加载。
需要跨目录或结构复杂？注册 app:// 协议
当 HTML 在 dist/app/、CSS 在 src/styles/，或者项目有多个入口页且路径关系不固定时，相对路径维护成本陡增。app:// 是唯一可扩展的长期方案，它让资源走 Chromium 允许的自定义通道。
- 注册必须在
app.whenReady()之后、BrowserWindow创建之前执行 - 回调中必须用
path.normalize()处理request.url.slice(6)拼出的路径，否则可能被../..遍历攻击 - HTML 中写
<link rel="stylesheet" href="app://css/main.css">，不是file:// - 注册后需重启应用才生效；开发时可在回调里加
console.log确认是否触发
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 建议用
fs.readFileSync(..., 'utf8').trim()清掉 BOM，避免解析失败
绝对路径 + file:// 协议风险高、兼容差
写 href="file://${path.join(...)}.css" 看似直白，但开发能跑、打包必崩。Electron 22+ 对 file:// 源更严格，CSP 必须显式声明 style-src 'self' file://，且路径必须完整、转义正确（Windows 下分隔符、空格、中文都要处理）。
-
__dirname和path.join()在主进程有效，但在 HTML 的href属性里无法执行，写死绝对路径毫无意义 - 路径拼接若未用
path.normalize()，可能被../绕过导致读取任意文件（安全漏洞） - 禁用
webSecurity: false能临时“修好”，等于拆掉防火墙，不推荐用于生产环境
真正容易被忽略的是：即使 fs.existsSync() 返回 true，Chromium 仍可能拒绝加载——这不是路径问题，而是协议级拦截，控制台错误不是 404，而是安全策略拒绝。
