LocalFontAccess API 并不存在于 HTML5 标准中，也未被任何主流浏览器实现；它因安全与隐私风险被W3C和浏览器厂商明确拒绝标准化，当前仅能通过navigator.fonts.query()等有限API探测已知字体。
LocalFontAccess API 目前并不存在于 HTML5 标准中，也未被任何主流浏览器实现。
这是关键前提——你无法通过 HTML5 或 Web API（包括 navigator.fonts、CSS Font Loading API 或 LocalFontAccess）直接读取用户系统上已安装的全部字体列表或访问本地字体文件（如 .ttf、.otf）。
为什么没有 LocalFontAccess？
出于明确的安全与隐私设计原则：
- 浏览器禁止网页随意探测用户系统环境，字体列表可能暴露操作系统类型、软件使用习惯、甚至职业特征（如设计师常装思源黑体、Adobe 字体）；
- 读取本地字体文件会绕过同源策略和沙箱机制，构成严重安全风险；
- W3C 和浏览器厂商（Chrome、Firefox、Safari）从未标准化或实现名为
LocalFontAccess的 API —— 它不属于 HTML5、CSSOM 或 Web Fonts 规范。
当前可用的字体相关 Web API（有限但合规）
虽然不能“读取系统字体”，但可通过以下方式支持专业排版：
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
-
navigator.fonts.query()（Chrome 124+，实验性）：可查询浏览器已知的、已加载或已启用的字体族名（如"Inter"、"Georgia"），但仅限于 CSS 中声明过@font-face或系统默认支持且已被渲染引擎识别的字体，不返回文件路径、字重范围或安装状态； -
CSS Font Loading API（
document.fonts.load()、document.fonts.ready）：用于预加载、检测指定字体是否可用并触发排版逻辑，适合控制 FOUT/FOIT； - @font-face + font-display：通过 CDN 或自托管字体文件，精确控制字重、样式、显示行为，是专业 Web 排版的事实标准；
-
CSS @supports font-tech()（部分支持）：可探测浏览器对可变字体（
font-tech("woff2-variations")）或彩色字体的支持能力。
替代方案：在可控环境中实现“类系统字体”体验
若目标是提升排版质量而非真实读取系统字体，可考虑：
-
预置高质量字体栈：按平台优化 fallback 链，例如：
font-family: "SF Pro Display", "Segoe UI", "Roboto", "Noto Sans CJK SC", system-ui;
利用各系统默认 UI 字体（system-ui）保证可读性与性能； -
按需加载 Web Fonts：用
<link rel="preload">+font-display: optional平衡速度与美观； - 服务端字体匹配（需用户授权）：桌面端应用（如基于 Electron 或 Tauri）可调用系统 API 获取字体列表，再通过安全 IPC 暴露给渲染进程 —— 但这已脱离纯 Web 范畴。
总结
所谓“利用 HTML5 中 LocalFontAccess 读取系统字体”是一个常见误解。目前没有任何标准 Web 技术允许网页直接枚举或加载用户本地字体文件。专业 Web 排版应聚焦于：
- 合理使用
@font-face与字体子集； - 善用
navigator.fonts.query()（注意兼容性）做轻量字体探测； - 结合 CSS 可变字体、font-feature-settings 实现高级排版控制；
- 尊重隐私边界，避免尝试绕过浏览器限制的 hack 方式。
