Chrome无法加载远程URL自定义字体，HTML邮件场景求解决方案

这事儿核心有两个关键点：

• Chrome的CORS校验更严格：Chrome对跨域加载字体的规则比其他浏览器苛刻得多。当你用绝对URL加载字体时，如果当前页面（或HTML邮件）的访问环境和字体文件所在域名不一致，Chrome会触发跨域资源共享（CORS）检查。如果你的服务器没配置正确的Access-Control-Allow-Origin响应头，Chrome直接就拒绝加载字体了——而其他浏览器对字体的CORS限制没这么严，所以能正常生效。
• HTML邮件的资源加载限制：HTML邮件和普通网页完全是两个环境，邮件客户端（包括浏览器打开的邮件）几乎都不支持本地相对路径的资源引用。因为邮件是独立的内容包，没有网页那样的服务器上下文，所以你之前在网页里能用的img/...相对路径，在邮件里根本找不到资源，只能用绝对URL，但又撞上了Chrome的CORS门槛。

针对HTML邮件的场景，给你三个可行的方案：

1. 配置字体服务器的CORS响应头 #

这是解决跨域问题的根本办法。登录你字体文件所在的服务器（也就是http://www.[mywebpage].com对应的服务器），在服务器配置里添加允许跨域访问字体的响应头：

• 如果是Apache服务器，在网站根目录的.htaccess文件里添加：

  <FilesMatch "\.(woff|woff2|ttf|otf)$">
      Header set Access-Control-Allow-Origin "*"
  </FilesMatch>
  

• 如果是Nginx服务器，在对应的server配置块里添加：

  location ~* \.(woff|woff2|ttf|otf)$ {
      add_header Access-Control-Allow-Origin *;
  }
  

  生产环境里如果能确定具体的访问域名，最好把*改成对应的域名列表，更安全；如果邮件可能在多个环境打开，用*更省心。配置完之后，Chrome就能正常跨域加载字体了。

2. 把字体内嵌到邮件里（最推荐） #

HTML邮件里最靠谱的方式就是绕开外部资源，直接把字体转换成Base64编码内嵌到CSS中。步骤很简单：

• 找个在线Base64转换工具，把你的bryant-light-webfont.woff文件转换成Base64编码字符串
• 修改@font-face代码，把URL换成Base64数据：

  @font-face {
      font-family: "Bryant-Light-LIV";
      src: url(data:application/font-woff;base64,这里替换成你的Base64编码内容) format("woff");
      font-weight:normal;
      font-style:normal;
      font-variant:normal;
  }
  

  这种方式完全避开了跨域和路径问题，几乎所有邮件客户端和浏览器都支持。唯一要注意的是，如果字体文件太大，会增加邮件体积，但woff格式本身已经做过压缩，一般不会有太大问题。

3. 添加字体降级方案 #

不管用哪种方法，都建议给字体声明加个系统默认字体作为备选，这样就算自定义字体加载失败，邮件内容也能正常显示：

body {
    font-family: "Bryant-Light-LIV", Arial, sans-serif;
}

内容的提问来源于stack exchange，提问作者Dan Cohen