CDN裁剪必须由服务端根据URL参数动态生成图片，路径式参数（如/w_800,h_450,c_fill/）比查询参数更可靠；核心参数w、h、fit、q、fm大小写敏感，缺失或拼错将退化为原图；fit=cover最常用，crop=auto需AI支持；srcset中每个URL的w值须与描述符严格一致；老版iOS Safari易截断查询参数，建议优先使用路径式写法。
CDN边缘侧动态剪裁不是前端加个object-fit就能生效的——它必须在请求发出前，由CDN服务端根据URL参数生成新图；路径式参数（如/w_800,h_450,c_fill/）比查询参数（?w=800&h=450&fit=cover）更可靠，尤其在老版iOS Safari里不会被截断。
CDN裁剪URL怎么写才被识别
不同CDN厂商参数名不统一，但核心字段基本一致：w、h、fit、q、fm。大小写敏感，拼错或缺失关键参数会退化为原图返回。
-
fit=cover：等比缩放+智能裁剪填满，最常用 -
fit=scale：仅缩放不裁剪，可能留白 -
crop=auto或fo=auto：启用AI焦点识别（需CDN支持） - Cloudflare Images示例：
https://imagedelivery.net/abc123/photo.jpg/w=800,h=450,fit=cover,q=80,fm=webp
srcset里怎么配CDN裁剪URL才不白发请求
每个srcset条目必须对应唯一固有宽度，且该宽度要和URL中w=值严格一致；否则浏览器无法匹配，可能反复加载同一张图。
- 错误写法：
srcset="https://cdn.com/photo.jpg?w=800 480w, https://cdn.com/photo.jpg?w=800 800w"（两个URL都是w=800，但描述符不同） - 正确写法：
srcset="https://cdn.com/photo.jpg?w=480&h=270&fit=cover 480w, https://cdn.com/photo.jpg?w=800&h=450&fit=cover 800w" -
sizes仍按容器渲染宽度写，和CDN参数无关 - 避免混用本地路径和CDN路径，缓存策略冲突会导致降级失效
为什么CDN裁剪在iOS Safari上突然失效
部分老版本iOS Safari（尤其是iOS 14及更早）会把带多个&的查询参数URL截断，导致h=、fit=等参数丢失，最终加载失败图。
立即学习“前端免费学习笔记（深入）”；
- 优先选支持路径式参数的CDN，例如Cloudinary的
/w_800,h_450,c_fill/或Imgix的/focalpoint/路径结构 - 若必须用查询参数，可对
&做URL编码（%26），但要确认CDN后端能解码 -
src回退地址必须是静态路径，不能含CDN参数，否则降级时也失效 - 启用CDN的query cache variant或路径缓存变体，避免参数组合爆炸导致缓存未命中
真正卡住人的地方不是参数怎么写，而是CDN是否真把fit=cover当裁剪指令执行——有些CDN只认c_fill或ar_16:9，文档不细读就容易白调半天。
