网站图片上传前的处理顺序：尺寸、格式与命名
图片问题大多发生在上传之前
网站打开慢、页面在手机上抖动、图片放大后发虚，排查时经常被归到服务器或代码上，但实际原因往往很简单：上传的原图是一张手机直出的四千像素照片，或者同一张图在列表页和详情页复用了同一个文件。前者让首屏每次都要多下载几 MB，后者则让某一处显示效果必然妥协。
图片处理有一条比较稳的顺序：先确定它在页面上的展示尺寸，再决定格式和压缩参数，然后统一命名和存放位置，最后在上传后逐项核对。顺序颠倒就会返工。比如先把图片压得很小，再发现要用在首屏大图上，只能重新找原图。
第一步：从展示位置倒推需要的尺寸
不要问“图片应该多大”，而要问“它显示在多大的容器里”。同一个网站通常只有几类固定容器：首屏横幅、栏目头图、列表缩略图、正文插图、图标与 logo。为每一类定一个宽度上限，其他尺寸按比例缩放，比逐张判断省事得多。
- 首屏横幅：按设计稿容器宽度的两倍准备，但设一个上限，例如不超过 1920 像素宽。
- 列表缩略图：按实际显示宽度的两倍即可，通常 400 到 600 像素宽足够。
- 正文插图：按内容区宽度的两倍，常见 1200 到 1600 像素宽。
- 图标与 logo：优先用 SVG，需要位图时按最大显示尺寸的两到三倍。
这里有个容易忽略的点：容器宽度在不同屏幕上并不相同。响应式布局下，一张图在电脑上占 800 像素宽，在手机上可能只占 350 像素宽。如果只准备一张大图，手机端就会多下载多余数据。是否要为移动端单独出小图，取决于站点是否支持按屏幕切换图片源；不支持时，宁可把主图压到中间值，也不要直接放最大尺寸。
第二步：格式与压缩的取舍
格式选择看图片内容，不看个人习惯。照片、有渐变的背景图用 JPG 或 WebP；需要透明背景的用 PNG 或 WebP；纯色块、线条图标、简单图形优先 SVG；动图只在确有必要时使用。
- JPG：通用性最好，压缩质量放在 75 到 85 之间通常已经看不出差异，继续往上加只会增加体积。
- WebP：相同观感下体积更小，但要先确认目标浏览器和后台都支持，导出前确认站点是否已有处理链路。
- PNG：只用于确实需要透明或硬边缘的情况。截图类图片存成 PNG 时体积往往很大，可以改存为高质量 JPG。
- SVG：适合图标和 logo，导出前清理编辑器产生的多余节点和隐藏图层。
压缩环节要注意只压一次。原始照片在设计师手里压过一次，运营在后台又用工具压一次，画质损失会叠加。比较稳妥的做法是保留原图存档，上传版本单独输出，并且固定由同一个环节完成压缩。
第三步：命名和存放位置
文件名会被搜索引擎、内容管理系统和以后接手的人看到，它是成本最低的规范之一。规则不用复杂，几条就够：全部小写英文，用连字符分隔单词，包含内容主题而不是日期和序号，去掉“最终版”“修改后”这类字样。
- 用 about-team-photo.jpg 这样的名字，不用 IMG_2043.jpg 或“图片1.jpg”。
- 按栏目分目录存放，例如产品图、案例图、新闻配图各一个目录，避免所有文件堆在根目录。
- 同一张图的不同用途分开导出并分别命名，不要用一个文件应付所有位置。
- 每张图填写的替代文字要描述图片内容，不要堆关键词，也不要直接复制文件名。
第四步：上传后的核对清单
图片进入后台之后，还需要确认它真的按预期工作。以下几项按顺序过一遍，大多数问题当场就能发现。
- 查看文件体积：单张正文插图尽量控制在 300 KB 以内，首屏大图控制在 500 KB 以内，超过就回头再压。
- 确认实际渲染尺寸：用浏览器开发者工具看图片在页面中的显示尺寸，如果显示 400 像素宽而文件是 2000 像素，说明尺寸没配对。
- 在手机上实际打开：不只看截图，要滑动整个页面，确认没有横向滚动、没有拉伸变形、没有图片错位。
- 检查加载表现：图片较多的页面启用懒加载后，要确认首屏图没有被延迟加载，否则会出现空白。
- 替换旧图后清缓存：同名替换最容易出问题，浏览器和 CDN 都可能返回旧文件，必要时改名或刷新缓存。
几处经常被漏掉的细节
第一类是图片里的文字。活动海报、资质证书、流程图直接以图片形式放上去，在手机上往往看不清，也无法被搜索到，能改成文字的尽量改成文字。第二类是图片中带出的信息，例如截图里露出的后台地址、内部编号、联系人手机号，这类内容一旦上线就不容易收回。
第三类是附件。招聘岗位说明、产品说明书、价目表常以 PDF 形式上传，扫描件未经处理时单份可能十几 MB，下载体验很差。建议先确认是否真的需要附件，再考虑压缩或转成网页内容。
第四类是批量上传。一次传几十张图时，顺序、命名和尺寸最容易乱。可以按栏目分批上传，每批完成后抽查两三张，比全部传完再回头找问题省时间。
规范的适用边界
上面这套流程适合图片更新频率不高、由少数人维护的站点。如果内容团队人数多、上新频繁，规则就要写进后台使用说明，甚至在上传环节做尺寸和体积的限制——靠人记不如靠工具挡。
另外，尺寸上限和体积上限不是硬指标，而是与页面结构、用户网络环境相匹配的经验值。图片本身就是核心内容时，例如案例图库、产品细节图，为了保证可用性可以放宽体积；反过来，只是装饰性的背景图，就应该压到更低。判断标准始终是：这张图承担什么作用，值不值这部分加载时间。