字体创意设计避坑：手写实现解决API变更痛点
版本升级后 API 全变了，这大概是每个前端或全栈工程师在维护老旧项目时最崩溃的时刻。昨天还能正常渲染的字体加载逻辑，今天一跑直接报 ReferenceError，文档里新加的 font-display 属性让你一脸懵。别急着去翻那些晦涩的新版文档，更别盲目复制网上那些过时的代码片段。今天我们要做的，是手写实现一套核心的字体加载与解析逻辑。不依赖任何第三方库，直接从底层协议开始拆解，让你彻底搞懂浏览器是如何处理字体的。一旦你明白了这套机制，无论 API 怎么变，你都能自己写出稳定的代码。
入口定位：从 HTTP 请求到字体解析
很多人以为字体加载就是个简单的 link 标签的事，其实背后是一条复杂的链路。当浏览器遇到 @font-face 规则时，它不会立即去下载字体文件，而是先检查本地缓存。如果没有，才会发起 HTTP 请求。这里的关键在于，字体文件（如 WOFF2）并不是普通文件，它有着特定的二进制结构。
根据 RFC 7230 规范，HTTP 消息的头部信息决定了资源如何被处理。虽然 RFC 7230 主要定义的是 HTTP/1.1 报文格式，但我们在处理字体时，必须关注 Content-Type 和 Accept 头。浏览器在请求字体时，会在 Accept 头中声明支持 font/woff2。如果服务器返回了错误的 MIME 类型，比如 application/octet-stream，浏览器可能会拒绝解析，或者在某些严格模式下直接报错。这就是为什么有时候你换了 CDN 节点，字体突然不显示的原因——往往是 CDN 配置了错误的响应头。
我们要关注的第一个入口，就是浏览器的字体加载状态机。在 Chrome DevTools 的 Network 面板中，你可以看到字体请求的状态变化：pending - loading - loaded。这个状态机背后，是由浏览器内部的 Font Loading 模块控制的。如果我们要手写实现，我们需要模拟这个状态管理。
核心片段：解析 WOFF 字体头结构
为了真正理解字体，我们需要看一眼 WOFF (Web Open Font Format) 文件的二进制结构。虽然现代浏览器多支持 WOFF2，但 WOFF1 的结构更简单，适合用来讲解原理。下面是一段解析 WOFF 文件头部的 JavaScript 代码，模拟了浏览器读取字体元数据的过程。
/**
* 手写实现：解析 WOFF 字体文件头部
* @param {ArrayBuffer} buffer - 字体文件的 ArrayBuffer
* @returns {Object} 字体头信息
*/
function parseWOFFHeader(buffer) {
// 1. 创建一个 DataView 用于读取二进制数据
// DataView 允许我们以特定字节序读取 ArrayBuffer
const view = new DataView(buffer);
// 2. 验证签名
// WOFF 文件的第一个 4 字节必须是 'wOFF'
// 读取前 4 个字节，将其视为无符号 32 位整数
const signature = view.getUint32(0, false);
// 'w' (0x77) 'O' (0x4F) 'F' (0x46) 'F' (0x46) 组合起来的十六进制
const WOFF_SIGNATURE = 0x774F4646;
if (signature !== WOFF_SIGNATURE) {
throw new Error('Invalid WOFF signature');
}
// 3. 读取 flavor (字体类型)
// 偏移量 4，读取 4 字节
// 通常 'true' 表示 TrueType, 'OTTO' 表示 OpenType/CFF
const flavor = new Uint8Array(buffer, 4, 4);
const fontType = String.fromCharCode(...flavor);
// 4. 读取长度
// 偏移量 8，读取 4 字节，大端序
const length = view.getUint32(8, false);
// 5. 读取表数量
// 偏移量 12，读取 2 字节
const numTables = view.getUint16(12, false);
console.log(`Font Type: ${fontType}, Length: ${length}, Tables: ${numTables}`);
return {
signature: 'WOFF',
fontType: fontType,
length: length,
numTables: numTables,
// 这里可以进一步解析表目录，定位 'glyf', 'cmap' 等关键表
};
}
这段代码的核心在于 DataView。很多开发者习惯用 Uint8Array，但它只能读取原始字节，无法直接处理多字节整数（如 32 位长度字段）。DataView 提供了 getUint32, getUint16 等方法，并允许指定字节序（大端或小端）。字体文件规范严格规定使用大端序（Big-Endian），所以在代码中第二个参数必须传 false。
设计思想：异步加载与 FOUT/FOIT 策略
字体加载是一个异步过程，而页面渲染是一个同步过程。这就产生了一个经典问题：闪动的不可见文本（FOIT） 或 闪动的非网页字体（FOUT）。
浏览器需要决定：在字体加载完成前，是显示空白（等待），还是显示备用字体（立即渲染）？这就是 font-display CSS 属性的用武之地。它的值包括 auto, block, swap, fallback, optional。
swap：立即使用备用字体渲染，字体加载完成后替换。这是用户体验最好的默认策略。
block：等待一小段时间（通常 3 秒），如果没加载完就显示备用字体。
optional：如果字体还没加载完，就永远不使用该字体。
我们要手写实现的，不仅仅是一个加载器，而是一个带有超时控制和状态回调的管理器。以下是一个简化的字体加载器类，它模拟了 font-display: swap 的行为，并加入了超时机制。
class FontLoader {
constructor(fonts, options = {}) {
// fonts: [{ family: 'MyFont', src: 'url(myfont.woff2)' }]
this.fonts = fonts;
this.timeout = options.timeout || 3000; // 默认 3 秒超时
this.onLoad = options.onLoad || (() = {});
this.onError = options.onError || (() = {});
this.loadedFamilies = [];
}
load() {
// 1. 创建 FontFace 对象数组
// FontFace 是 Web Font API 的核心接口
const fontFaces = this.fonts.map(font = {
return new FontFace(font.family, font.src);
});
// 2. 并行加载所有字体
// 使用 Promise.all 确保所有字体都尝试加载
const promises = fontFaces.map(fontFace = {
return new Promise((resolve, reject) = {
// 3. 设置超时
// 即使字体服务器响应极慢，我们也要在 timeout 后强制 resolve 或 reject
const timer = setTimeout(() = {
// 超时后，我们选择 resolve，让页面继续使用备用字体
// 这模拟了 font-display: swap 的行为
resolve('timeout');
}, this.timeout);
fontFace.load()
.then((loadedFace) = {
clearTimeout(timer);
// 将字体添加到文档中
// 这一步是关键，只有添加到 document，CSS 才能使用它
document.fonts.add(loadedFace);
this.loadedFamilies.push(fontFace.family);
resolve('success');
})
.catch((error) = {
clearTimeout(timer);
// 加载失败，记录错误
reject(error);
});
});
});
// 4. 等待所有字体加载完成（或超时）
Promise.allSettled(promises)
.then(results = {
const successes = results.filter(r = r.status === 'fulfilled').length;
console.log(`Loaded ${successes} fonts`);
this.onLoad(this.loadedFamilies);
// 触发 document.fonts.ready 类似的逻辑
// 在实际应用中，可以派发一个自定义事件
window.dispatchEvent(new Event('custom-fonts-ready'));
})
.catch(error = {
console.error('Font loading error:', error);
this.onError(error);
});
}
}
这段代码展示了如何脱离浏览器默认行为，手动控制字体的加载时机。document.fonts.add() 是很多人忽略的一步。仅仅调用 fontFace.load() 只是下载了文件，并没有将其注册到文档中，CSS 规则无法生效。
手写简化版：从零构建字体监控器
前面的代码依赖了 FontFace API，这在现代浏览器中是标准的。但如果我们要做极致的手写实现，甚至兼容更底层的环境，或者需要更精细的控制（如预加载、字体子集化），我们可以写一个更底层的监控器。这个版本不直接操作 FontFace 对象，而是通过 DOM 测量技术来判断字体是否可用。
这是一种古老但依然有效的技巧：创建一个隐藏的 div，分别用默认字体和目标字体渲染同一个字符串，比较它们的宽度。如果宽度不同，说明目标字体已加载。
/**
* 手写实现：基于 DOM 测量的字体加载检测器
* 原理：如果字体加载完成，文本宽度会发生变化
*/
function checkFontLoaded(familyName, fallbackFont = 'monospace') {
return new Promise((resolve) = {
// 1. 创建两个测试元素
// 一个使用目标字体，一个使用回退字体
const testString = 'mmmmmmmmmmlli'; // 包含易混淆字符
const fontSize = '100px';
// 目标字体容器
const targetDiv = document.createElement('div');
targetDiv.style.fontFamily = `'${familyName}', ${fallbackFont}`;
targetDiv.style.fontSize = fontSize;
targetDiv.style.visibility = 'hidden';
targetDiv.style.position = 'absolute';
targetDiv.style.top = '0';
targetDiv.style.left = '0';
targetDiv.textContent = testString;
// 回退字体容器
const fallbackDiv = document.createElement('div');
fallbackDiv.style.fontFamily = fallbackFont;
fallbackDiv.style.fontSize = fontSize;
fallbackDiv.style.visibility = 'hidden';
fallbackDiv.style.position = 'absolute';
fallbackDiv.style.top = '0';
fallbackDiv.style.left = '0';
fallbackDiv.textContent = testString;
// 2. 添加到 DOM 中（必须是可见的 DOM 树，即使 CSS 隐藏）
// 注意：display: none 会导致 offsetWidth 为 0，所以用 visibility: hidden
document.body.appendChild(targetDiv);
document.body.appendChild(fallbackDiv);
// 3. 获取初始宽度
// 此时目标字体可能尚未加载，所以宽度应该等于回退字体
const fallbackWidth = fallbackDiv.offsetWidth;
let targetWidth = targetDiv.offsetWidth;
// 4. 如果初始宽度不同，说明字体已缓存
if (targetWidth !== fallbackWidth) {
cleanup();
resolve(true);
return;
}
// 5. 轮询检查
// 使用 requestAnimationFrame 比 setInterval 更高效，因为它与渲染循环同步
let checkCount = 0;
const maxChecks = 30; // 大约 0.5 秒内检查 30 次
function check() {
targetWidth = targetDiv.offsetWidth;
checkCount++;
// 如果宽度发生变化，说明字体加载完成
if (targetWidth !== fallbackWidth) {
cleanup();
resolve(true);
return;
}
// 如果达到最大检查次数，认为加载失败或超时
if (checkCount = maxChecks) {
cleanup();
resolve(false);
return;
}
// 继续下一帧检查
requestAnimationFrame(check);
}
function cleanup() {
document.body.removeChild(targetDiv);
document.body.removeChild(fallbackDiv);
}
requestAnimationFrame(check);
});
}
这个手写实现的最大优势在于它不依赖任何现代 API，兼容性极强。它利用了浏览器渲染引擎的核心特性：文本布局是字体相关的。当你切换字体族时，字符的度量（metrics）会改变，从而导致容器宽度改变。
应用场景：在构建工具中预加载字体
了解了原理和实现，我们来看一个实际的应用场景：在 Webpack 或 Vite 等构建工具中，如何自动提取 CSS 中的字体并生成预加载提示。
很多大型前端项目因为字体加载慢导致 LCP (Largest Contentful Paint) 指标下降。通过在 HTML 头部添加 link rel=preload href=font.woff2 as=font type=font/woff2 crossorigin，可以告诉浏览器尽早下载字体。
我们可以写一个简单的插件，扫描 CSS 文件，提取 @font-face 规则，并注入预加载标签。
/**
* 伪代码：Webpack/Vite 插件逻辑
* 扫描 CSS，提取字体 URL，生成预加载 HTML
*/
function extractFontPreloads(cssContent) {
const preloadTags = [];
// 使用正则表达式匹配 @font-face 中的 src
// 简化版，实际项目中应使用 postcss 解析
const fontRegex = /src:\s*url\(([^)]+)\)/g;
let match;
while ((match = fontRegex.exec(cssContent)) !== null) {
const fontUrl = match[1].replace(/[']/g, '');
// 判断字体类型
let type = 'font/woff2';
if (fontUrl.endsWith('.woff')) type = 'font/woff';
if (fontUrl.endsWith('.ttf')) type = 'font/ttf';
const preloadTag = `link rel=preload href=${fontUrl} as=font type=${type} crossorigin`;
preloadTags.push(preloadTag);
}
return preloadTags.join('\n');
}
将这段逻辑集成到构建流程中，可以显著提升首屏字体渲染速度。结合前文的手写实现监控器，你甚至可以做一个更智能的策略：如果检测到用户网络速度慢，就跳过预加载，直接使用系统字体，等字体下载完再无缝切换。
结尾
字体看似简单，实则是前端性能优化中的一个深水区。从 HTTP 头部的 MIME 类型，到二进制文件的表结构解析，再到 DOM 布局的测量技巧，每一个环节都藏着细节。当你不再依赖那些黑盒的库，而是能够手写实现核心逻辑时，你对自己代码的控制力将达到一个新的高度。
你在项目里踩过这个坑吗？比如字体加载导致页面抖动，或者 CDN 配置错误导致字体无法解析？评论区聊聊，看看大家有什么更野的解决思路。 
长河君 · 2026/9/22 1:34:31 · 阅读 1.2k 字体创意设计避坑：手写实现解决API变更痛点
字体创意设计避坑：手写实现解决API变更痛点
版本升级后 API 全变了，这大概是每个前端或全栈工程师在维护老旧项目时最崩溃的时刻。昨天还能正常渲染的字体加载逻辑，今天一跑直接报 ReferenceError，文档里新加的 font-display 属性让你一脸懵。别急着去翻那些晦涩的新版文档，更别盲目复制网上那些过时的代码片段。今天我们要做的，是手写实现一套核心的字体加载与解析逻辑。不依赖任何第三方库，直接从底层协议开始拆解，让你彻底搞懂浏览器是如何处理字体的。一旦你明白了这套机制，无论 API 怎么变，你都能自己写出稳定的代码。
入口定位：从 HTTP 请求到字体解析
很多人以为字体加载就是个简单的 link 标签的事，其实背后是一条复杂的链路。当浏览器遇到 @font-face 规则时，它不会立即去下载字体文件，而是先检查本地缓存。如果没有，才会发起 HTTP 请求。这里的关键在于，字体文件（如 WOFF2）并不是普通文件，它有着特定的二进制结构。
根据 RFC 7230 规范，HTTP 消息的头部信息决定了资源如何被处理。虽然 RFC 7230 主要定义的是 HTTP/1.1 报文格式，但我们在处理字体时，必须关注 Content-Type 和 Accept 头。浏览器在请求字体时，会在 Accept 头中声明支持 font/woff2。如果服务器返回了错误的 MIME 类型，比如 application/octet-stream，浏览器可能会拒绝解析，或者在某些严格模式下直接报错。这就是为什么有时候你换了 CDN 节点，字体突然不显示的原因——往往是 CDN 配置了错误的响应头。
我们要关注的第一个入口，就是浏览器的字体加载状态机。在 Chrome DevTools 的 Network 面板中，你可以看到字体请求的状态变化：pending - loading - loaded。这个状态机背后，是由浏览器内部的 Font Loading 模块控制的。如果我们要手写实现，我们需要模拟这个状态管理。
核心片段：解析 WOFF 字体头结构
为了真正理解字体，我们需要看一眼 WOFF (Web Open Font Format) 文件的二进制结构。虽然现代浏览器多支持 WOFF2，但 WOFF1 的结构更简单，适合用来讲解原理。下面是一段解析 WOFF 文件头部的 JavaScript 代码，模拟了浏览器读取字体元数据的过程。
/**
* 手写实现：解析 WOFF 字体文件头部
* @param {ArrayBuffer} buffer - 字体文件的 ArrayBuffer
* @returns {Object} 字体头信息
*/
function parseWOFFHeader(buffer) {
// 1. 创建一个 DataView 用于读取二进制数据
// DataView 允许我们以特定字节序读取 ArrayBuffer
const view = new DataView(buffer);
// 2. 验证签名
// WOFF 文件的第一个 4 字节必须是 'wOFF'
// 读取前 4 个字节，将其视为无符号 32 位整数
const signature = view.getUint32(0, false);
// 'w' (0x77) 'O' (0x4F) 'F' (0x46) 'F' (0x46) 组合起来的十六进制
const WOFF_SIGNATURE = 0x774F4646;
if (signature !== WOFF_SIGNATURE) {
throw new Error('Invalid WOFF signature');
}
// 3. 读取 flavor (字体类型)
// 偏移量 4，读取 4 字节
// 通常 'true' 表示 TrueType, 'OTTO' 表示 OpenType/CFF
const flavor = new Uint8Array(buffer, 4, 4);
const fontType = String.fromCharCode(...flavor);
// 4. 读取长度
// 偏移量 8，读取 4 字节，大端序
const length = view.getUint32(8, false);
// 5. 读取表数量
// 偏移量 12，读取 2 字节
const numTables = view.getUint16(12, false);
console.log(`Font Type: ${fontType}, Length: ${length}, Tables: ${numTables}`);
return {
signature: 'WOFF',
fontType: fontType,
length: length,
numTables: numTables,
// 这里可以进一步解析表目录，定位 'glyf', 'cmap' 等关键表
};
}
这段代码的核心在于 DataView。很多开发者习惯用 Uint8Array，但它只能读取原始字节，无法直接处理多字节整数（如 32 位长度字段）。DataView 提供了 getUint32, getUint16 等方法，并允许指定字节序（大端或小端）。字体文件规范严格规定使用大端序（Big-Endian），所以在代码中第二个参数必须传 false。
设计思想：异步加载与 FOUT/FOIT 策略
字体加载是一个异步过程，而页面渲染是一个同步过程。这就产生了一个经典问题：闪动的不可见文本（FOIT） 或 闪动的非网页字体（FOUT）。
浏览器需要决定：在字体加载完成前，是显示空白（等待），还是显示备用字体（立即渲染）？这就是 font-display CSS 属性的用武之地。它的值包括 auto, block, swap, fallback, optional。
swap：立即使用备用字体渲染，字体加载完成后替换。这是用户体验最好的默认策略。
block：等待一小段时间（通常 3 秒），如果没加载完就显示备用字体。
optional：如果字体还没加载完，就永远不使用该字体。
我们要手写实现的，不仅仅是一个加载器，而是一个带有超时控制和状态回调的管理器。以下是一个简化的字体加载器类，它模拟了 font-display: swap 的行为，并加入了超时机制。
class FontLoader {
constructor(fonts, options = {}) {
// fonts: [{ family: 'MyFont', src: 'url(myfont.woff2)' }]
this.fonts = fonts;
this.timeout = options.timeout || 3000; // 默认 3 秒超时
this.onLoad = options.onLoad || (() = {});
this.onError = options.onError || (() = {});
this.loadedFamilies = [];
}
load() {
// 1. 创建 FontFace 对象数组
// FontFace 是 Web Font API 的核心接口
const fontFaces = this.fonts.map(font = {
return new FontFace(font.family, font.src);
});
// 2. 并行加载所有字体
// 使用 Promise.all 确保所有字体都尝试加载
const promises = fontFaces.map(fontFace = {
return new Promise((resolve, reject) = {
// 3. 设置超时
// 即使字体服务器响应极慢，我们也要在 timeout 后强制 resolve 或 reject
const timer = setTimeout(() = {
// 超时后，我们选择 resolve，让页面继续使用备用字体
// 这模拟了 font-display: swap 的行为
resolve('timeout');
}, this.timeout);
fontFace.load()
.then((loadedFace) = {
clearTimeout(timer);
// 将字体添加到文档中
// 这一步是关键，只有添加到 document，CSS 才能使用它
document.fonts.add(loadedFace);
this.loadedFamilies.push(fontFace.family);
resolve('success');
})
.catch((error) = {
clearTimeout(timer);
// 加载失败，记录错误
reject(error);
});
});
});
// 4. 等待所有字体加载完成（或超时）
Promise.allSettled(promises)
.then(results = {
const successes = results.filter(r = r.status === 'fulfilled').length;
console.log(`Loaded ${successes} fonts`);
this.onLoad(this.loadedFamilies);
// 触发 document.fonts.ready 类似的逻辑
// 在实际应用中，可以派发一个自定义事件
window.dispatchEvent(new Event('custom-fonts-ready'));
})
.catch(error = {
console.error('Font loading error:', error);
this.onError(error);
});
}
}
这段代码展示了如何脱离浏览器默认行为，手动控制字体的加载时机。document.fonts.add() 是很多人忽略的一步。仅仅调用 fontFace.load() 只是下载了文件，并没有将其注册到文档中，CSS 规则无法生效。
手写简化版：从零构建字体监控器
前面的代码依赖了 FontFace API，这在现代浏览器中是标准的。但如果我们要做极致的手写实现，甚至兼容更底层的环境，或者需要更精细的控制（如预加载、字体子集化），我们可以写一个更底层的监控器。这个版本不直接操作 FontFace 对象，而是通过 DOM 测量技术来判断字体是否可用。
这是一种古老但依然有效的技巧：创建一个隐藏的 div，分别用默认字体和目标字体渲染同一个字符串，比较它们的宽度。如果宽度不同，说明目标字体已加载。
/**
* 手写实现：基于 DOM 测量的字体加载检测器
* 原理：如果字体加载完成，文本宽度会发生变化
*/
function checkFontLoaded(familyName, fallbackFont = 'monospace') {
return new Promise((resolve) = {
// 1. 创建两个测试元素
// 一个使用目标字体，一个使用回退字体
const testString = 'mmmmmmmmmmlli'; // 包含易混淆字符
const fontSize = '100px';
// 目标字体容器
const targetDiv = document.createElement('div');
targetDiv.style.fontFamily = `'${familyName}', ${fallbackFont}`;
targetDiv.style.fontSize = fontSize;
targetDiv.style.visibility = 'hidden';
targetDiv.style.position = 'absolute';
targetDiv.style.top = '0';
targetDiv.style.left = '0';
targetDiv.textContent = testString;
// 回退字体容器
const fallbackDiv = document.createElement('div');
fallbackDiv.style.fontFamily = fallbackFont;
fallbackDiv.style.fontSize = fontSize;
fallbackDiv.style.visibility = 'hidden';
fallbackDiv.style.position = 'absolute';
fallbackDiv.style.top = '0';
fallbackDiv.style.left = '0';
fallbackDiv.textContent = testString;
// 2. 添加到 DOM 中（必须是可见的 DOM 树，即使 CSS 隐藏）
// 注意：display: none 会导致 offsetWidth 为 0，所以用 visibility: hidden
document.body.appendChild(targetDiv);
document.body.appendChild(fallbackDiv);
// 3. 获取初始宽度
// 此时目标字体可能尚未加载，所以宽度应该等于回退字体
const fallbackWidth = fallbackDiv.offsetWidth;
let targetWidth = targetDiv.offsetWidth;
// 4. 如果初始宽度不同，说明字体已缓存
if (targetWidth !== fallbackWidth) {
cleanup();
resolve(true);
return;
}
// 5. 轮询检查
// 使用 requestAnimationFrame 比 setInterval 更高效，因为它与渲染循环同步
let checkCount = 0;
const maxChecks = 30; // 大约 0.5 秒内检查 30 次
function check() {
targetWidth = targetDiv.offsetWidth;
checkCount++;
// 如果宽度发生变化，说明字体加载完成
if (targetWidth !== fallbackWidth) {
cleanup();
resolve(true);
return;
}
// 如果达到最大检查次数，认为加载失败或超时
if (checkCount = maxChecks) {
cleanup();
resolve(false);
return;
}
// 继续下一帧检查
requestAnimationFrame(check);
}
function cleanup() {
document.body.removeChild(targetDiv);
document.body.removeChild(fallbackDiv);
}
requestAnimationFrame(check);
});
}
这个手写实现的最大优势在于它不依赖任何现代 API，兼容性极强。它利用了浏览器渲染引擎的核心特性：文本布局是字体相关的。当你切换字体族时，字符的度量（metrics）会改变，从而导致容器宽度改变。
应用场景：在构建工具中预加载字体
了解了原理和实现，我们来看一个实际的应用场景：在 Webpack 或 Vite 等构建工具中，如何自动提取 CSS 中的字体并生成预加载提示。
很多大型前端项目因为字体加载慢导致 LCP (Largest Contentful Paint) 指标下降。通过在 HTML 头部添加 link rel=preload href=font.woff2 as=font type=font/woff2 crossorigin，可以告诉浏览器尽早下载字体。
我们可以写一个简单的插件，扫描 CSS 文件，提取 @font-face 规则，并注入预加载标签。
/**
* 伪代码：Webpack/Vite 插件逻辑
* 扫描 CSS，提取字体 URL，生成预加载 HTML
*/
function extractFontPreloads(cssContent) {
const preloadTags = [];
// 使用正则表达式匹配 @font-face 中的 src
// 简化版，实际项目中应使用 postcss 解析
const fontRegex = /src:\s*url\(([^)]+)\)/g;
let match;
while ((match = fontRegex.exec(cssContent)) !== null) {
const fontUrl = match[1].replace(/[']/g, '');
// 判断字体类型
let type = 'font/woff2';
if (fontUrl.endsWith('.woff')) type = 'font/woff';
if (fontUrl.endsWith('.ttf')) type = 'font/ttf';
const preloadTag = `link rel=preload href=${fontUrl} as=font type=${type} crossorigin`;
preloadTags.push(preloadTag);
}
return preloadTags.join('\n');
}
将这段逻辑集成到构建流程中，可以显著提升首屏字体渲染速度。结合前文的手写实现监控器，你甚至可以做一个更智能的策略：如果检测到用户网络速度慢，就跳过预加载，直接使用系统字体，等字体下载完再无缝切换。
结尾
字体看似简单，实则是前端性能优化中的一个深水区。从 HTTP 头部的 MIME 类型，到二进制文件的表结构解析，再到 DOM 布局的测量技巧，每一个环节都藏着细节。当你不再依赖那些黑盒的库，而是能够手写实现核心逻辑时，你对自己代码的控制力将达到一个新的高度。
你在项目里踩过这个坑吗？比如字体加载导致页面抖动，或者 CDN 配置错误导致字体无法解析？评论区聊聊，看看大家有什么更野的解决思路。