最近写主题，然后涉及字体问题，很麻烦，又没找到 （也没仔细找）合适的字体载入工具，所以就自己写一个好了。
- 创建一个文件夹用来放字体，在插件设置中载入这个文件夹
- 可以给字体设置别名（用来引用），不设置别名（留空）则此字体不被启用
- 可以使用载入的字体覆盖界面（UI）、正文、代码字体
- 可以在主题或者 CSS 片段中引用对应的字体（使用别名）
基本就这样。
【特点】：性能上应该比使用 base64 嵌入的方式好一些，支持移动端。
2 个赞
我现在用的是Custom Font Loader，是可以从.obsidian目录下读取字体的，这玩意的缺点就是会在插件目录生成一个巨大的css文件。想问问这两个的实现原理不同在哪
好问题！
性能差异
- Custom font loader 使用的是将字体文件转换为 base64，嵌入 CSS 文件的方式
- DMS fonts loader 使用的是将字体读取到内存，然后用 blob URI 引入的方式
我让 AI 写了一下差异，略长，附在下面：
AI 分析
在 Obsidian 中，字体的加载方式对软件的启动速度（首屏渲染）和内存占用有很大影响。这两个插件采用了截然不同的底层逻辑，我们来逐一分析它们的性能差异和优缺点：
1. 技术原理对比
-
Custom Font Loader (Base64 嵌入法)
-
原理：将本地的字体文件（如
.ttf、.woff2）编码为一长串 Base64 文本，然后直接写入到一个.css文件（或data:URI）中。 -
渲染链：Obsidian 加载 CSS \\rightarrow 解析 Base64 文本为二进制 \\rightarrow 注册并渲染字体。
-
-
DMS Fonts Loader (Blob URI 内存法)
-
原理：插件启动时，通过 Node.js/Electron API 读取本地字体文件到内存中，将其转化为一个二进制的大对象（Blob），并生成一个类似
blob:app://...的本地 URL，再通过标准 CSS 的@font-face引入。 -
渲染链：Obsidian 启动 \\rightarrow 异步读取文件到内存 \\rightarrow 生成 Blob URL \\rightarrow 浏览器原生加载 URL 渲染字体。
-
2. 核心性能指标对比
启动速度与首屏渲染（冷启动）
-
Custom Font Loader（较慢）：由于 Base64 字符串体积比原字体文件大约 33%，Obsidian 在启动时需要加载一个非常庞大的 CSS 文件。更致命的是，CSS 的解析是阻塞渲染的。在低配设备（如手机、软路由/同步盘上的老电脑）上，这会导致明显的软件启动白屏或卡顿。
-
DMS Fonts Loader（较快）：它通常采用异步或更轻量的方式读取文件，生成的 Blob URI 只是一个非常短的字符串（指针）。Obsidian 可以瞬间解析完 CSS 结构，而字体的实际加载交给浏览器的原生网络模块异步完成，不会阻塞主线程渲染，首屏速度更快。
内存与 CPU 消耗
-
Custom Font Loader（高消耗）：
-
内存：V8 引擎（Obsidian 的底层）需要常驻这段巨大的 Base64 文本字符串，同时还要在内存中解压一份二进制字体，造成了双倍的内存开销。
-
CPU：每次重新加载、更改主题或启动时，CPU 都需要进行 Base64 编解码计算。
-
-
DMS Fonts Loader（低消耗）：
- Blob 对象在内存中是以原始二进制形式存在的，由内核直接管理。它不需要经过复杂的文本解码，内存占用基本等同于字体文件原本的大小，对 CPU 几乎没有额外开销。
文件体积与同步开销
-
Custom Font Loader（大）：因为体积膨胀了 33%，如果你使用中文字体（动辄 10MB-30MB），转换后的 CSS 可能会达到 40MB。这会严重拖慢 Obsidian 各种同步服务（如 Obsidian Sync, Git, 坚果云）的同步速度。
-
DMS Fonts Loader（小）：插件本身只记录字体路径或只在运行时动态生成，不污染配置文件，同步压力极小。
3. 综合对比看板
| 维度 | Custom Font Loader (Base64) | DMS Fonts Loader (Blob URI) | 获胜者 |
|---|---|---|---|
| 启动速度 | 较慢（大 CSS 阻塞渲染） | 快（异步/原生加载） | DMS Fonts Loader |
| 内存占用 | 较高（文本+二进制双重占用） | 极低（原生二进制内存） | DMS Fonts Loader |
| CPU 消耗 | 解码时有瞬间高负载 | 几乎无感 | DMS Fonts Loader |
| 大字体支持 | 极差（中文字体容易导致卡死） | 良好（大字体也能轻松驾驭） | DMS Fonts Loader |
| 兼容性与稳定性 | 极高（纯 CSS，全平台通用） | 略受限于运行环境的 API | Custom Font Loader |
总结与建议
-
如果你使用的是英文字体（体积通常 < 500KB）：两者的性能差异在现代电脑上几乎无法察觉。Custom Font Loader 凭借纯 CSS 的高稳定性，反而是个省心的选择。
-
如果你使用的是中文字体（体积通常 > 5MB）：强烈建议使用 DMS Fonts Loader（或类似的 Blob URI 引入插件）。Base64 方案在面对几十兆的中文字体时，会导致 Obsidian 移动端或低配 PC 出现灾难性的启动延迟。
简言之，面对中文字体，尤其多个中文字体，推荐选用我的插件，性能差异明显。
灵活性
- Custom font loader 只能选择一个字体，然后全局应用
- DMS fonts loader 完全对应外观设置中界面、正文、代码的字体设定，三处可以分别设定，并可以设置不同字体
与其他样式的配合
DMS fonts loader 载入的字体可以被其他主题、样式片段、插件、脚本等进行引用。方便进行个性化。（本来就是为了方便我的主题做更细致的效果而开发的
感谢解答！
另外扫描不到.obsidian这样的隐藏目录是API限制还是别的什么原因？我倾向于放在配置目录里
使用官方 API，直接读取仓库下文件，应该是直接忽略掉隐藏目录的吧，这样扫描什么的都可以走官方 API。我不是很确定……
虽然应该可以支持隐藏目录，但是我觉得没什么必要。理由如下：
我觉得字体也算是一种附件，反正笔记仓库总是要有各种附件的，就算没有附件，还有一些插件需要有额外的文件等，这些文件我都会统一到一个文件夹下（然后按具体功能分子文件夹），所以把字体文件放在这些一起非常合理。反之，即便把字体文件放入 .obsidian “隐藏”起来，这些附件和插件依赖/关联文件也没办法都隐藏吧，那就没必要分开处理了。
真心好用，特别是移动端 