自己的图片被别的网站直接引用时，靠哪个响应头决定放不放行

自己的图片被别的网站直接引用时，靠哪个响应头决定放不放行，这个头的解释权在资源一方，而不是引用它的那一站。Cross-Origin-Resource-Policy 就是由资源自己声明的一层策略：它告诉浏览器，这份资源允许被哪些来源加载，不符合声明的跨站请求就在客户端被挡下来。要放行还是收紧，改的是自己站点上资源的响应头，对方站点无需配合。

谁有权声明资源能被谁引用

一层容易混淆的地方在于，页面和它可以引用的资源分属两方。发起页面那侧的隔离头说的是「我这个上下文里允许装进来什么」，资源这侧的声明说的是「我这份东西能让谁拿去用」。同一个跨站引用能不能成，取决于两端声明的交集，任何一端收紧都会导致加载失败。所以排查时不要只盯着出错页面，被引用资源的响应头里有没有合适的策略，是另一条独立的线索。

三个取值分别放行到哪一层

三档之间不是宽严的偏好问题，而是资源准备让谁用。同一份文件挂到不同目录，取值也可以不同，粒度是按响应来的。

默认挡住的是哪一类请求

这层策略针对的是不带 cors 的跨来源或跨站请求，也就是图片、脚本、样式这类直接以子资源形式加载的请求。浏览器读到收紧的声明，就把这类请求挡在客户端，资源的响应本身仍然照常发出，服务端并不参与判断。这一点决定了它的作用面：管得住浏览器要不要显示，管不住有人绕过浏览器直接要文件。

图片与字体各自要不要放开

图片常被站外引用，收紧到同源会立刻在自家别的子站上也看不到，放开到跨来源又要接受带宽被消耗。字体往往必须放开到跨来源，因为引用它的页面本来就来自别的站点，挡下来等于字体全站失效。两者取舍通常按目录区分：需要外发的素材走一条带宽松声明的路径，站内专用素材保持收紧。

这层声明挡不住什么

站内的防采集干扰码针对的是内容被拿走之后怎么处理——它作用在正文内容里，用来降低批量搬运得到的东西的质量。资源来源策略是另一层，只管浏览器加载这一步。把两者当同一件事，容易出现「图都在，采集却拿走了正文」的判断偏差。真要减少被直接引用的消耗，还得回到来源声明、目录划分与访问量控制这几处。

常见问题

问：只改发起页面的隔离头够不够？ 答：不够。被引用资源这侧的声明是独立一层，两端都放行才能加载成功；资源方收紧时，页面侧再宽松也不会放开。

问：换协议或换端口会不会影响同源判断？ 答：会。同源看的是协议、主机与端口三项，任意一项不同就不算同源，这类改动常把原本正常的图片判断成跨来源。

问：设成跨来源是不是等于允许抓取？ 答：不等于。这层只决定浏览器让不让某个来源加载这份资源，对直接请求文件的抓取行为没有约束力。