我之前排查过类似的Headless Chrome字体加载问题，结合你描述的场景——Windows 32/64位、Chrome 79（含Canary）、仅无头模式下Google Fonts加载失败，这里有几个可落地的解决方案：

1. 添加字体渲染与沙箱相关启动参数 #

Headless模式默认的字体渲染配置和正常模式有差异，加上以下参数可以修复大部分字体加载异常：

chrome.exe --headless --disable-gpu --enable-font-antialiasing --force-color-profile=srgb --no-sandbox https://fonts.google.com

• --enable-font-antialiasing：强制启用字体抗锯齿，确保字体渲染流程完整
• --force-color-profile=srgb：统一色彩配置，避免字体文件解析时的色彩空间冲突
• --no-sandbox：关闭Windows下的沙箱限制，部分场景下沙箱会拦截外部字体资源请求

2. 检查系统字体依赖 #

Headless Chrome依赖系统字体库完成字体加载的基础流程，如果Windows缺少基础字体（比如Arial、微软雅黑），可能导致外部字体加载失败：

• 手动安装常用系统字体包
• 启动时显式指定系统字体目录：

  chrome.exe --headless --disable-gpu --font-path="C:\Windows\Fonts" https://fonts.google.com
  

3. 生成详细日志定位具体错误 #

如果上面的方法没效果，建议开启日志排查具体的加载失败原因：

chrome.exe --headless --disable-gpu --enable-logging --v=1 https://fonts.google.com

启动后，Chrome会在用户数据目录生成chrome_debug.log文件，你可以从中查看字体请求的状态码（比如403、404）、CORS错误或文件解析失败信息，精准定位问题。

4. 调整Chrome版本或UA字符串 #

• 版本切换：Chrome 79的Headless模式确实存在一些字体加载的已知bug，你可以尝试降级到Chrome 78稳定版，或者更新到最新的Canary版本，看是否已经修复该问题
• 修改User-Agent：部分字体服务会针对Headless模式的UA做拦截，模拟正常浏览器的UA可以绕过限制：

  chrome.exe --headless --disable-gpu --user-agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36" https://fonts.google.com
  

如果以上方案都无法解决问题，建议将详细的日志、系统版本、Chrome版本信息提交到Chrome官方issue tracker，方便官方团队定位修复。

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