Vite不处理字体跨域，需前端@font-face加crossorigin:anonymous且后端配Access-Control-Allow-Origin等响应头；Vite proxy不代理字体请求，file://协议下必报CORS错。
JavaScript 中 Vite 本身不直接处理字体文件的跨域问题，真正起作用的是浏览器对 @font-face 的 CORS 策略限制。Vite 作为构建工具，只负责打包和开发服务器转发；而字体加载失败（如 “Font from origin has been blocked”）属于资源请求阶段的跨域拦截，需从前端声明 + 后端响应两方面协同解决。
前端：在 @font-face 中显式声明 crossorigin
即使字体与页面同源，也建议加上 crossorigin 属性，避免浏览器以非 CORS 模式发起请求导致服务端拒绝：
- 使用
crossorigin: anonymous（推荐）：不携带 Cookie，服务端可返回Access-Control-Allow-Origin: * - 避免省略该属性：否则浏览器可能按“普通请求”处理，无法读取响应头，字体加载静默失败
- 示例写法：
@font-face {
font-family: 'IconFont';
src: url('https://cdn.example.com/fonts/icon.woff2') format('woff2');
font-display: swap;
crossorigin: anonymous;
}
```
后端：确保字体资源响应头包含正确 CORS 配置
字体文件所在服务器（CDN 或静态资源服务）必须返回合法的跨域响应头：
Node.js 可靠编程
下载
Node.js 可靠编程技能。避免事件循环阻塞、异步陷阱、ESM 兼容问题和内存泄漏。触发词：Node.js 开发、async/await、流处理、性能优化、安全编码。
-
Access-Control-Allow-Origin：若前端用anonymous，可设为*；若需带凭证（如 Cookie），必须指定具体域名，不能用* -
Access-Control-Allow-Methods: GET（必需） -
Access-Control-Allow-Headers（按需，一般 GET 字体无需额外头） - Nginx 示例配置：
location ~* \.(woff2|woff|ttf|eot)$ {
add_header Access-Control-Allow-Origin "*";
add_header Access-Control-Allow-Methods "GET";
add_header Access-Control-Max-Age "31536000" always;
}
```
开发环境特别注意：Vite dev server 不代理字体请求
Vite 的 server.proxy 只代理匹配路径的 HTTP 接口请求（如 /api/xxx），**不会代理 CSS 中 @font-face 的字体资源请求**。因此：
立即学习“Java免费学习笔记（深入）”；
- 不要指望把
url('https://api.com/font.woff2')写进 CSS 后靠 proxy 转发——它不会生效 - 本地调试时，字体应放在
public/目录下，用相对路径引用（如url('/fonts/icon.woff2')），由 Vite 开发服务器直出，天然同源 - 若必须从外部域名加载，就只能依赖对方服务开启 CORS，或改用 base64 内联（仅适合小图标字体）
补充：打包后 file:// 协议打开也会报字体 CORS 错误
如果双击 dist/index.html 运行，浏览器使用 file:// 协议，此时 origin 为 null，任何外部字体都会被拦截。这不是 Vite 配置问题，而是浏览器安全机制：
- 解决方案：用本地 HTTP 服务启动（如
npx serve -s dist或vite preview） - 避免在生产环境依赖
file://加载跨域字体
