很多站点在内容和结构上做了不少工作，却很少认真看过图片。图片是页面里平均体积最大的一类资源，也是最容易长期堆积、逐渐失控的部分。改版一次加一批图，活动结束没人清理，几年下来目录里躺着几千个用不上的文件。这篇整理一套日常就能做的媒体资源自查流程，不需要重构，也不需要动模板底层。
为什么把图片单独拎出来检查
图片问题通常有三个特点：一是不容易在页面上被察觉，缩略图看起来都正常；二是影响面广，一张图可能同时出现在列表页、详情页和推荐位；三是修复成本低，压缩、改名、补 alt 基本不需要开发排期。正因为如此，它属于投入产出比较高的运营动作。
体积与格式：先看一眼总量
打开浏览器开发者工具的网络面板，按体积排序，看看排在最前面的十个请求是什么。多数站点会发现，前几名清一色是图片。
- 单图体积：正文插图控制在合理区间，超过一定尺寸的原图直接上传，往往就是主要负担。
- 格式选择：照片类适合有损压缩格式，图标和纯色图形适合矢量或无损格式，带透明通道的图要区分场景。不必追求最新格式，优先保证兼容。
- 尺寸匹配：列表页展示的是缩略图，就不要用原始大图靠 CSS 缩小，浏览器实际下载的仍是完整文件。
- 响应式：同一张图在手机和桌面端有不同的展示宽度，若条件允许，用不同尺寸的源文件而不是一份通吃。
命名、替代文本与目录结构
图片文件名既是给系统看的，也是给维护者看的。类似 IMG_20230417_001.jpg 这种命名，半年后自己都分不清是哪张。建议用简短、可读、语义清晰的英文或拼音命名，保持全站风格一致，避免同义词混用。
替代文本不是给搜索引擎凑字数的，它的第一用途是无障碍和图片加载失败时的兜底说明。写法上描述图片内容即可，不必堆关键词，也不必每张图都强行加。装饰性图片留空更合适。
目录结构上，建议按业务模块或时间归档，而不是全部堆在同一个 upload 目录里。分目录的好处是迁移、清理和排查都更容易定位。
懒加载与首屏图片
懒加载能显著减少首屏请求，但用错地方会适得其反。首屏可见区域的图片应当正常加载，甚至提高优先级；屏幕外的图片再延迟加载。常见错误是把首屏主图也加上懒加载属性，结果用户看到的是一片空白，然后图片才慢慢浮现。
另外，图片没有设定宽高时，加载完成会导致页面内容跳动。给图片容器预留尺寸，或在标签上写明宽高比例，这类细节对阅读体验的影响其实比想象中大。
失效图片与外部引用
图片失效往往发生在几种情况：图床更换、文件被误删、路径大小写在服务器上不敏感但在其他环境下敏感、引用的站外图片被对方下线或加了防盗链。
- 定期扫描页面中的图片地址，检查返回状态，把失效项列成清单逐条处理。
- 站外引用的图片尽量落地到自己的服务器或对象存储，避免对方调整策略后连带影响自己的页面。
- 图片的协议写法保持一致，避免在 HTTPS 页面里混入不安全的资源引用。
清理与归档
清理是整套流程里最容易拖延的一环。可以先做低风险的动作：把确认不再使用、且没有被任何页面引用的文件移到归档目录，观察一段时间，确认没有异常再删除。删除前保留一份备份，删除记录写进变更日志，方便回溯。
需要提醒的是，判断“没人用”不能只靠感觉。列表页配置、轮播图、模板里的默认图、邮件模板、APP 端接口，都可能引用同一个文件。清理之前先做一次全量引用检索。
一个可执行的检查顺序
- 抓取主要模板页面的资源请求，按体积排序，找出最大的十张图。
- 检查这些图的格式、尺寸是否与展示位置匹配，能压的压缩，能换尺寸的换尺寸。
- 抽查一批图片的文件名与替代文本，修正明显无意义的命名。
- 核对首屏图片是否被错误地延迟加载，补齐宽高属性。
- 扫描失效图片和站外引用，逐条替换或落地。
- 导出长期未引用的文件清单，先归档，后清理，并记录在案。
媒体资源治理不需要一次性做完，把它拆成几件小事，按季度做一轮，效果比集中大扫除更稳。做完之后，页面的加载表现和维护难度都会轻松一些。