说到CDN图片缓存策略的选择，这真是个让人又爱又恨的话题。记得上次网站优化时，我盯着Lighthouse报告里那串红色的”图片未优化”警告，差点把头发抓秃。WebP格式固然能大幅减小体积，但要是CDN缓存策略没配好，所有的优化都可能白费功夫——就像我那次惨痛的Cloudflare经历，明明浏览器支持WebP，却硬是给我塞了几百KB的JPEG。
缓存键设计：别让CDN”认错人”
你知道吗？大多数CDN默认只根据URL缓存图片，这可是个大坑！我花了三天时间才搞明白，为什么用户总是收到错误的图片格式。关键在于那个叫做”Vary: Accept”的HTTP头，它告诉CDN要根据浏览器支持的格式来区分缓存。现在我的Nginx配置里永远躺着这几行代码：
# 根据Accept头区分WebP缓存
map $http_accept $webp_suffix {
default "";
"~*webp" ".webp";
}缓存时长：要持久也要灵活
有人觉得图片缓存越久越好，我曾经也这么想——直到遇到那次全站图片更新的灾难。现在我的策略是分层设置：
- 指纹化资源（带hash的URL）：1年缓存
- 非指纹化资源：1周缓存+即时清除能力
- 用户上传内容：30天缓存+版本控制
这个方案在电商网站特别实用，商品主图可以长期缓存，而促销banner又能随时更新。
边缘计算：让CDN更”聪明”
最近在测试Cloudflare的Image Resizing功能时，简直像发现了新大陆！现在我可以让CDN边缘节点直接转换图片格式和尺寸，再配合他们的Polish产品，流量费居然比自建图片服务器还便宜30%。不过要注意的是，这种动态处理对缓存命中率的影响，我的经验是至少要保留源站20%的备用处理能力。
说到底，好的CDN图片策略就像穿衣服——既要保暖（缓存效率），又要方便脱换（更新灵活）。每次调整策略后，记得用WebPageTest多跑几次地理位置测试，我就是在测试东京节点时发现了一个诡异的缓存不一致问题。大家如果有更好的实战经验，欢迎在评论区分享啊！
评论