electron 中通过 `@font-face` 引入位于 `resources/fonts/` 目录下的自定义字体时，因缺少 `format()` 壁垒声明或路径解析问题导致 `err_file_not_found`，本文提供完整、可靠的修复方案。
在 Electron 应用中正确加载自定义字体，需同时满足路径有效性与CSS 规范性两个前提。你当前的目录结构合理（resources/fonts/ 作为字体专用目录），且 HTML 中 CSS 的引入方式（css/config.css">）也符合标准，但问题核心在于：@font-face 的 src 声明不完整，且 Electron 渲染进程对本地文件协议（file://）的资源解析比浏览器更严格。
✅ 正确的 @font-face 写法（关键修复）
必须显式指定字体格式（format()），否则 Chromium 渲染引擎可能拒绝加载（尤其在 file:// 协议下）：
/* css/config.css */
@font-face {
font-family: 'nexusBody';
src: url('../resources/fonts/DidactGothic-Regular.ttf') format('truetype');
font-weight: normal;
font-style: normal;
}
@font-face {
font-family: 'nexusCapiters';
src: url('../resources/fonts/OdibeeSans-Regular.ttf') format('truetype');
font-weight: normal;
font-style: normal;
}? 注意事项：format('truetype') 中的 'truetype' 必须加单引号（CSS 字符串语法）；.ttf 对应 truetype，.otf 对应 opentype，.woff2 对应 woff2 —— 格式必须严格匹配；推荐补充 font-weight 和 font-style，避免浏览器回退默认值引发渲染异常。
? 路径验证：确保相对路径在运行时有效
Electron 渲染进程解析 CSS 中的 url(...) 时，基准路径是该 CSS 文件所在位置（即 css/ 目录），因此 ../resources/fonts/... 是完全正确的。你可以通过以下方式验证路径是否真实可达：
- 在 index.html 中临时添加调试脚本：
- 若控制台报 404，请检查构建/打包后资源是否被遗漏（如使用 electron-builder，需在 build.files 中显式包含 resources/**/*）。
⚠️ 不要滥用 app.setPath('resources', ...)
app.setPath('resources') 用于修改 Electron 内部的 resources 目录（影响 app.getPath('resources') 等 API），与前端静态资源加载路径无关。强行调用不仅无效，还会因 Electron 主进程初始化时机问题（如在 ready 事件前调用）导致 Failed to set path 错误 —— 这正是你遇到的 UnhandledPromiseRejectionWarning 根源。请彻底移除该代码。
✅ 最佳实践建议
- 字体文件统一存放于 resources/fonts/（你已做到，保持即可）；
- CSS 中始终使用 format() 显式声明，并校验扩展名与格式名一致；
- 开发阶段开启 DevTools → Network 标签页，过滤 font 类型，直观查看字体请求状态；
- 生产打包时确认资源未被忽略（例如 electron-builder 的 extraResources 或 files 配置需包含 resources/**/*）；
- 如仍失败，可临时将字体转为 Base64 内联（仅调试用）：
src: url('data:font/truetype;charset=utf-8;base64,...') format('truetype');
遵循以上步骤，你的 nexusBody 和 nexusCapiters 字体将稳定生效，无需妥协将字体文件降级至 css/ 目录 —— 既保障项目结构清晰，又符合 Electron 工程化规范。
