curl -s 'https://cdn.example.com/api/cache/stats?prefix=/uploads/' # 输出 keys 与 bytes 两组数字
媒体库只有 9000 张原图，边缘存储三天从 12GB 涨到 92GB，请求数没涨，存储项翻了七倍，账单里多出一大截。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。
追下去是这么回事：页面里同一张图带了 w=120、240、480 等十二种参数，缓存键按完整 URL 计算，每个宽度各存一份。参数顺序和多余的小数位也会算成不同键，重复量被继续放大。
这次卡住的地方就在「裁剪缓存重复」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。同一份配置存在多处的，先确认改的是被加载的那一份。
新版本先放一台机器上跑一天再全量，问题一般在这段时间暴露。
处理上按这个顺序：先按 URL 前缀统计边缘缓存的键数量，确认重复来自哪些参数；把宽度收敛成固定档位，参数按统一顺序拼接，去掉无意义的小数；给不常用的档位设较短 TTL，或让边缘缓存原图后实时裁剪。
确认没问题再收工，同一批图在边缘的键数量降到原来的三分之一，存储增速回落。