字体文件404说明服务器未找到文件，需检查：文件是否真实存在且路径大小写精确匹配；Nginx是否配置了正确优先级的字体扩展名location块；CSS中@font-face的url()路径是否相对于CSS文件位置、格式声明是否与实际文件类型一致。
字体文件加载返回 404，说明浏览器发出了请求，但 Web 服务器根本没找到那个文件——它压根没进 PHP 或前端路由，问题一定出在静态资源路径、服务器配置或文件系统层面。
检查字体 URL 是否真实可访问
打开浏览器开发者工具 → Network → 过滤 font，点开那个 404 的请求，复制完整 URL（比如 https://yoursite.com/static/fonts/icon.woff2），直接粘贴到新标签页里访问。
- 如果仍是 404：确认文件是否真放在
public/static/fonts/下（ThinkPHP8 推荐放public/子目录） - Linux 服务器严格区分大小写：
iconfont.woff2≠IconFont.woff2，必须和 CSS 中@font-face src: url(...)里的名字完全一致 - 检查文件权限：
ls -l public/static/fonts/，确保www-data或nginx用户有读权限（至少-rw-r--r--）
Nginx location 配置误吞字体请求
常见错误是 location / 块里写了太宽泛的 try_files $uri $uri/ /index.php?$query_string，结果字体请求找不到文件后被甩给 /index.php，而 PHP 不处理 .woff2，最终返回 404 或空白。
- 必须单独配一个显式匹配字体扩展名的
location块，且要放在location /之前（Nginx 按最长匹配优先） - 正确写法示例：
location ~* \.(woff2|woff|ttf|eot|svg)$ { expires 1y; add_header Cache-Control "public, immutable"; } - 漏掉
.woff2或把这段写在location /后面，都会失效
@font-face 中的 url() 路径计算错误
url() 是相对于 CSS 文件位置解析的，不是 HTML 页面路径，也不是服务器根目录。本地双击打开 HTML（file:// 协议）也会因跨域被拦截，必须走 HTTP 服务。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- CSS 在
css/style.css，字体在fonts/icon.woff2，就得写url('../fonts/icon.woff2') - 绝对路径要带开头斜杠：
url('/static/fonts/icon.woff2')（前提是服务器 DocumentRoot 指向public/） - 路径里含中文、空格或全角符号，某些浏览器会直接跳过整个
@font-face块 - 构建工具（如 Vite）可能把字体输出到
assets/xxx.woff2，但 CSS 里还引用着原始路径，需检查构建后产物
format() 声明与实际文件类型不匹配
format() 不校验内容，只是提示浏览器“这是什么格式”。声明错会导致旧版 Safari、IE 等直接拒绝加载，现象就是控制台无报错、字体显示方块或回退默认字体。
-
.woff2文件必须写format('woff2')，不能写format('woff') -
.ttf对应format('truetype')，.eot对应format('embedded-opentype') - 多个
src可用逗号分隔，浏览器按顺序尝试，但每个format()都得和对应文件严格一致
最容易被忽略的是：字体请求根本不会触发 PHP 或任何框架逻辑，排查时必须跳出「是不是路由没配对」的惯性思维，直奔文件系统和 Web 服务器配置。Nginx 的 location 顺序、Linux 的大小写敏感、CSS 中相对路径的基准点——这三个点踩中任意一个，就稳稳 404。
