服务器处理图片跨域与缓存，最稳的姿势是：跨域用Nginx统一加CORS响应头，缓存用Cache-Control加CDN分层，两者配合能挡住绝大多数重复请求。
服务器图片跨域问题怎么解决？先拆开看三层
图片跨域，本质是浏览器的同源策略在卡脖子，服务器和服务器之间没有跨域这回事，但浏览器加载跨域图片时，会看响应头里有没有允许跨域的声明，你作为服务器管理员，要做的就是替图片说话，把Access-Control-Allow-Origin加到图片响应里。
静态图片的Nginx跨域配置
行业共识认为，静态图片资源最省事的办法是在Nginx里按文件类型匹配，编辑站点配置文件，在server块里加这么一段：
location ~ .(jpg|jpeg|png|gif|webp|avif)$ {
add_header Access-Control-Allow-Origin ;
add_header Access-Control-Allow-Methods GET, OPTIONS;
}
这段配置会让所有图片带上允许跨域的响应头，表示任何域名都能加载，适合公开图片，如果图片涉及用户隐私或需要登录态，就不能用通配符,改成具体域名，
add_header Access-Control-Allow-Origin https://www.example.com;
带自定义头时得处理预检
虽然<img>标签加载图片是简单GET请求，但如果你用fetch、axios或者canvas刮擦像素数据时带了自定义头，浏览器会先发一次OPTIONS预检请求，Nginx如果不理这个预检,后面的GET照样被拦截。
所以在图片location里,要同时回应预检：
if ($request_method = OPTIONS) {
add_header Access-Control-Allow-Origin ;
add_header Access-Control-Allow-Headers ;
add_header Access-Control-Max-Age 86400;
return 204;
}
Access-Control-Max-Age告诉浏览器，一天之内别再发预检了，直接发正式请求，这个数字单位是秒，86400就是24小时，设置合理的话,跨域图片的加载延迟会明显下降。
跨域报错时怎么排查
常见现象是：浏览器控制台提示"No 'Access-Control-Allow-Origin' header"，先确认Nginx配置是否生效，用nginx -t检查语法，然后
nginx -s reload重载，再用curl模拟请求,看响应头里有没有那一行：
curl -I -H "Origin: https://www.example.com" https://你的服务器地址/sample.jpg
响应头里出现access-control-allow-origin就说明配置到位，没有的话，检查是不是被CDN缓存了旧响应,或者有其他反向代理把响应头吞掉了。
图片缓存配置方法：从响应头到CDN一层层来
缓存和跨域是两码事，但实际部署时经常在同一台服务器上处理，缓存的核心目标是：图片尽可能少回到源站取，合理配置后，源站负载能降一个量级,用户加载速度也更快。
源站Nginx缓存头设置
最简单的方式是使用Nginx自带的expires指令，这个指令会自动生成Cache-Control和Expires两个头。
location ~ .(jpg|jpeg|png|gif|webp)$ {
expires 30d;
}
这表示图片在浏览器里缓存30天，30天后浏览器会向服务器发起条件请求，问图片变没变，如果没变，服务器返回304，不传图片内容,节省带宽。
想更精细一点，手动写Cache-Control头：
add_header Cache-Control "public, max-age=2592000, immutable";
immutable告诉浏览器：这个图片在有效期内绝对不变，不用再发请求验证，对带版本号的静态资源特别合适，如果你时不时会原地覆盖同名图片，千万别加immutable,否则用户要等缓存过期才能看到新图。
CDN图片缓存策略怎么定
图片量大了以后，源站直接面对用户请求很吃亏，业内专家指出，CDN缓存策略要遵循“源站短缓存、边缘长缓存”的规律，源站设置max-age=300，只给CDN中间层一个短时间；CDN节点上对图片设置7天或30天的缓存，这样做的好处是：管理员更新图片时，只要在CDN控制台刷新缓存，源站上的短TTL能保证新版本快速生效,不会一直留着旧图。
具体操作路径大致是：
- 登录CDN控制台,找到域名管理。
- 进入缓存配置页,新建规则。
- 匹配路径填
.jpg
、
.png这类后缀,或者指定某个图片目录。 - 过期时间填7天或30天，优先于源站头就选“源站优先”或“CDN覆盖”取决于你的需求。
缓存验证里的ETag和Last-Modified
如果强缓存没命中，浏览器会发起协商缓存，Nginx默认开启了ETag，响应头里会有ETag和Last-Modified，服务器收到If-None-Match或If-Modified-Since后，判断图片没改,直接返回304空响应。
注意，如果你自己写了add_header Cache-Control，可能会覆盖掉默认的ETag行为？实际上不会，但如果你用了proxy_pass把请求转发给后端应用，就需要确保后端不吞掉ETag，最稳妥的做法是：Nginx前端只负责加跨域头和基本缓存头，后端的图片文件由Nginx直接处理,不要经过应用服务器。
跨域和缓存同时存在时怎么配置
前面把跨域和缓存分开说了，实际生产环境里它们要同时出现在同一个location里，幸好响应头之间互不干扰，可以叠着加,完整示例：
location ~ .(jpg|jpeg|png|gif|webp)$ {
# 跨域头
add_header Access-Control-Allow-Origin ;
add_header Access-Control-Allow-Methods GET, OPTIONS;
# 缓存头
expires 30d;
add_header Cache-Control "public, max-age=2592000";
# 预检回应
if ($request_method = OPTIONS) {
add_header Access-Control-Allow-Headers ;
add_header Access-Control-Max-Age 86400;
return 204;
}
}
这段配置里，expires和手动写的Cache-Control会同时存在，多数情况下，手动写的值会覆盖expires生成的值，所以只用一种方式写清楚就行，别两个都写,容易乱。
缓存失效怎么办：图片更新了用户还是旧图
这是图片缓存里最头疼的问题，解决办法主要有三个,按推荐程度排序：
- 修改文件名，每次上传新图就生成新的文件名，比如
avatar_20260101.jpg，文件名变了，URL就变了,CDN和浏览器都会把它当新资源加载。 - 加查询参数，在不改文件名的情况下，URL后面拼
?v=2，但要注意，有些CDN默认忽略查询参数，需要先在CDN缓存规则里设置“缓存完整URL”或者“缓存键包含查询参数”。 - 主动刷新CDN缓存，在CDN控制台输入图片URL，选择“刷新URL”或“刷新目录”，刷新目录会影响整个目录下所有文件，成本高,精准刷新单个URL更经济。
运营图片和用户图片得区别对待
用户头像、商品主图这类基本不变化的图片，缓存时间可以拉到30天或更长，但运营banner、活动海报频繁更换，缓存时间设置太长的话，活动改了用户还是旧图，这种情况建议把缓存时间压到5到10分钟，配合CDN刷新接口,在每次活动发布后自动触发刷新。
图片跨域与缓存问题Q&A
Nginx配了跨域头，图片还是报跨域错误？
先确认你配置的位置对不对。add_header放在location里比放在server里优先级更高，但如果配置在if条件里，有些情况下不会生效，还要检查CDN回源时，是不是把源站的响应头给去掉了，用curl带上Origin头去请求CDN域名，看响应头里有没有access-control-allow-origin，没有的话，还要在CDN控制台里增加返回头配置,把跨域头加到CDN层面。
图片缓存时间设多长最合适？
没有统一答案，但有一个参考基准：头像、图标、字体这类几乎不变的资源，设30天，新闻配图、活动页面里的图片，缓存时间设在5分钟到1小时之间，更难办的是那种不确定何时更新的图片，可以在源站用Cache-Control: no-cache强制每次回源验证，但配上ETag让服务端只返回304,实际传输的数据量很小。
CDN回源时图片响应头被重置了，怎么处理？
在CDN控制台找到回源HTTP头配置，确认没有删除源站的access-control-allow-origin，有些CDN默认会覆盖源站的Cache-Control，如果你需要CDN的缓存策略覆盖源站，这没问题，但跨域头必须保留，否则浏览器端直接拦截，碰到这类问题，先在CDN上把“回源跟随”和“HOST回源”设置好，再在CDN缓存规则里把图片类型的“忽略源站缓存头”选项关掉,让源站的跨域头能一路透传到浏览器。