内容平台、电商店铺和企业官网里，图片往往是最费资源的部分。一张高清商品图动辄几MB，页面慢、带宽账单高、手机上翻图卡顿，根子常常在图片怎么存、怎么发。阿里云在这块的产品分工很清楚，对象存储OSS负责存，CDN负责送，图片处理负责按需生成尺寸。三者组合起来，就能把图片从原始素材一路管到用户屏幕上。下面从存储、加速、处理、安全四个环节，逐步说明具体怎么配。
一、图片为什么不能一直放在服务器目录里
很多团队起步时都是把图片丢进服务器目录，页面直接引用。规模小的时候没什么问题，访问量一上来，麻烦会接连出现：
- 磁盘占用涨得快，备份和迁移一次要花很长时间。
- 图片请求占满源站带宽，动态接口跟着变慢。
- 手机和电脑要的尺寸不同，设计师手动裁剪，版本很快就乱了。
- WebP、AVIF这类现代格式需要统一输出，靠人工很难维持。
把存储、分发、处理拆开管，各自都能独立扩展，比把所有压力压在服务器上省心得多。
二、第一步，在OSS里把原图存好
OSS是整套方案的底座。创建Bucket时有几个参数最好提前想清楚，后面改起来比较麻烦。
地域
地域尽量选在用户或业务服务器附近。业务主力在华东，就选华东的Bucket。同地域的ECS访问OSS走内网，延迟低，也不产生公网流量费用。
存储类型和读写权限
商品主图、首页轮播这类天天被访问的图，用标准存储。历史活动图、归档素材几乎没人看，放到低频访问或归档类型，存储费能省下来。公开展示的图片可以设为公共读，但写权限要收紧，别把整个Bucket开放写入。上传尽量通过STS临时凭证或服务端签名完成，AccessKey不要写进前端代码，一旦泄露，图片可能被随意覆盖。
目录结构
目录规则定得清楚，后面的清理和授权都会省事。比如按“业务/年月/类型/文件名”组织，像 product/202406/main/sku-10023.jpg 这样。按月份可以批量清理，按前缀也能在权限和生命周期规则里精确匹配。
三、第二步，用CDN把图片送到用户附近
图片放进OSS后，外网已经能访问，但用户离源站越远，加载就越慢。接入阿里云CDN，把图片缓存到边缘节点，是最常见的做法。
操作上，在CDN控制台添加加速域名，源站类型选OSS域名，再把CNAME记录指过去。之后页面里的图片地址从OSS域名换成加速域名，其他代码通常不用动。
案例：家居店铺的首页图片
一家做家居用品的中型店铺，首页挂着大量商品主图和活动海报，图片一直从自建服务器读取。大促时服务器带宽经常打满，首屏超过4秒是常态。改造时他们做了三件事：图片迁到OSS华东Bucket，接入CDN并开启缓存，首页图片设置较长的缓存时间。改完后首屏降到1.5秒左右，服务器带宽压力明显下降。这次改造的收益不只是快，还把图片流量从源站身上挪开了。
四、第三步，按需生成尺寸，别再人工导出
同一张图通常要好几个版本。PC端要宽图，手机端要竖图，列表页要缩略图，详情页要大图。每个版本都让设计师手动导出，既耗时，版本还容易混。
阿里云的图片处理支持在图片地址后追加URL参数，实时完成缩放、裁剪、格式转换和质量调整。比如加上宽度参数并指定WebP格式，就能拿到对应版本。原图只存一份，前端根据设备宽度选择地址，不用为每个尺寸单独出图。
实时处理会计费，首次请求也会有一点延迟。如果某个固定尺寸的访问量很大，可以提前生成一份存进OSS，之后直接读取，省掉重复计算。
案例：资讯站的配图
一个资讯网站早先为了适配手机，把文章配图压得很小，结果电脑端看着发糊。后来改成存一份高清原图，前端按屏幕宽度请求对应规格，统一输出WebP。图片总体积比之前少了约四成，清晰度没有下降。这里的关键动作是先把原图留好，再决定每个终端给多大。
五、安全和成本，容易漏掉的几项
- 防盗链，在CDN或OSS里配置Referer白名单。名单里别忘了自己的域名，否则正常页面的图片也会加载失败。
- 生命周期规则，给临时上传目录、过期活动图设置自动转存或删除，否则存储量会一直往上走。
- 访问日志，开启后能看出哪些图片最热门、哪些几乎没人点开，据此调整存储策略。
- 鉴权URL，付费内容或私密图片使用带签名和过期时间的地址，链接转出去也很快失效。
账单上建议固定每月看三项：存储量、外网流量和处理次数。超支通常不是某一个大项目造成的，多半是某个小环节长期没人盯着。
六、落地顺序
第一次上手，可以按下面的顺序推进：
- 先统计现有图片的数量、体积和访问分布，弄清楚问题出在哪。
- 创建OSS Bucket，定好目录规则和权限策略。
- 接入CDN，先给访问量最高的图片加速，观察一段时间的效果再扩大范围。
- 配置图片处理规则，逐步替换人工裁剪流程。
- 设置成本监控和生命周期规则，把日常维护固定下来。
单看每一张图都不起眼，加在一起却会直接影响页面速度和运营成本。先解决对业务伤害最大的那一环，比一次把所有功能都开起来更实际。
