这里的要求在Font fetching requirements section in the CSS Fonts spec中定义：
对于字体加载，用户代理必须使用 [HTML5] 规范为@font-face 规则中定义的 URL 定义的可能启用 CORS 的 fetch 方法。获取时，用户代理必须使用“匿名”模式，将引用源设置为样式表的 URL，并将源设置为包含文档的 URL。
这对作者的影响是字体通常不会跨域加载，除非作者特别采取措施允许跨域加载。站点可以使用Access-Control-Allow-Origin 明确允许跨站点加载字体数据。
“可能启用 CORS 的获取”和“匿名”状态的组合实际上是为了使跨域字体获取始终启用 CORS（不仅仅是“可能”）——因为 @987654322 @：
+-----------+-----------+---------------------------------------------------------+
| anonymous | Anonymous | Requests for the element will have their mode set to |
| | | "cors" and their credentials mode set to "same-origin". |
+-----------+-----------+---------------------------------------------------------+
鉴于所有这些，以下是您问题的具体答案：
- 字体是否始终受 CORS 政策约束？为什么？
是的，使用 @font-face 进行跨域字体加载始终受 CORS 政策的约束，根据上面引用的 CSS 字体规范和 HTML 规范的规范要求。
至于为什么，和this comment有相关讨论：
主要原因是字体供应商希望 Web 作者将字体的使用限制在他们自己的网站上，而 Web 作者无法轻松可靠地做到这一点，除非我们提供同源限制
在同一个讨论中，this comment：
同源策略适用于网络上几乎所有新的资源类型。只有少数遗留资源类型（图像、脚本、css 和呃、音频/视频（几乎没有错过这些））允许跨域页面无限制地热链接。
现在这是网络的标准安全实践。
那么回答你的下一个问题：
- 为什么图像不受 CORS 政策的约束？
图像是上面引用的评论中提到的“少数遗留资源类型”之一，它们相对来说已经成为 Web 的一部分，并且一直被允许跨域加载。字体等较新的功能（在过去几年中添加）的不同之处在于，如今为此类功能添加支持时，默认情况下它们被限制为同源。
- 如果字体受 CORS 约束，它与图像在 CORS 方面有何不同？
不确定您要问什么，但我认为答案是，就 CORS 而言，以触发 CORS 限制的方式请求的图像与任何跨域请求的图像没有区别。
我的意思是，如果不是使用 img 元素来加载图像，而是使用 XHR 或 Fetch API 来请求它，那么您的浏览器将对该图像请求应用同源限制，只是因为您的浏览器会处理您请求跨域的任何其他内容。
不同之处在于 img 元素早在我们知道我们现在所知道的之前就已经设计好了，因此它在浏览器中的跨域 OK 处理与我们对这些新功能的默认同源处理不同天。
换句话说，img 元素的处理实际上是这里规则的例外，而对字体的处理与浏览器现在对所有新功能的处理是一致的。