你在百度浏览器里用@font-face加载自定义字体，最直接的感受就是：字体死活不生效。

中文字体变成黑体，英文字母显示成方块或系统默认字体。

更让人头疼的是，打开开发者工具一看，既没有报错，也没有明显的网络警告。

问题往往不在代码本身，而在浏览器对本地文件的处理策略。

说白了就是：百度浏览器对file://协议下加载字体，采取了更严格的限制。

我先直接说结论：直接拖入百度浏览器打开的HTML文件，无法加载任何woff2或ttf字体。这个限制是根源性的，也是排查路径的起点。

确认字体文件是否真正被请求并返回成功

打开百度浏览器，访问目标页面，按F12打开开发者工具，切换到Network选项卡。

刷新页面后，在筛选框中输入woff2、ttf或font，就能看到所有字体资源的请求状态。

• 如果状态码是404，说明浏览器根本没找到文件。
• 如果是0或显示(failed)，那十有八九是file://协议限制或跨域拦截搞的鬼——百度浏览器对本地HTML文件执行更严格的字体策略，这就是前面说的那个核心限制。

再看响应头里的Content-Type。

• 如果是font/woff2、font/ttf或application/font-woff，那没问题。
• 但要是返回text/plain或空值，服务器没有正确配置MIME类型，百度浏览器会直接拒绝解析。

验证@font-face中url()路径是否相对于CSS文件位置

这个坑踩的人不少：@font-face里的url()路径，基准点不是HTML文件所在目录，而是CSS文件本身的位置。

举个例子：CSS文件在/static/css/app.css，字体文件在/static/fonts/icon.woff2。

那么url()里必须写'../fonts/icon.woff2'——是从CSS文件出发的相对路径。

要是写成'/fonts/icon.woff2'，浏览器会尝试请求https://当前域名/fonts/icon.woff2，而不是项目内的真实路径。

怎么验证？开发者工具里点开对应字体请求，在Headers里复制Request URL，直接在新标签页打开。

如果打不开或提示403，那就是路径或服务器权限配置有问题。

检查百度浏览器对woff2格式的实际支持与降级策略

先看内核版本。地址栏输入about:version，查看WebKit内核版本或Blink版本。

百度浏览器主流版本基于Chromium 115–122，理论上原生支持woff2，但部分定制版确实存在解码模块阉割的情况。

但更稳妥的做法，是提供多格式降级。仅声明woff2风险太高：

@font-face {
    font-family: 'MyIcon';
    src: url('icon.woff2') format('woff2'),
         url('icon.woff') format('woff'),
         url('icon.ttf') format('truetype');
}

关键就在这里：百度浏览器遇到woff2加载失败时，不会自动尝试下一个src，除非你明确写出多个format()并用逗号分隔。

漏掉任意一个format()字符串，整条规则都会被静默忽略。

排查font-family调用与声明的一致性

打开Elements面板，选中设置了自定义字体的元素。

在Computed标签页里看font-family最终生效的是什么。

然后回溯到Styles面板，找到生效的font-family声明，核对它和@font-face里声明的值是否完全一致——大小写、空格、引号，一个都不能差。

还有一点要特别提醒：百度浏览器禁用所有local()字体回退。

如果@font-face中src包含了local()，比如src: local('HarmonyOS Sans'), url('icon.woff2')，整条规则很可能被跳过。

务必将local()移除，只保留url()引用。

绕过百度浏览器字体策略的临时验证法

如果上述排查都做了，字体还是不显示，那大概率是file://协议封锁策略导致的。

这时候不要再纠结路径或语法了，换个方式验证：

启动一个轻量本地服务，彻底避开file://协议限制。

安装Node.js，在项目根目录打开命令行，执行npx http-server -c-1（-c-1表示禁用缓存），然后浏览器访问http://127.0.0.1:8080/对应的页面。

这一步能立刻告诉你答案：如果本地服务下字体正常显示，那100%是百度浏览器对本地协议的字体封锁策略所致，根本不需要再调代码。