企业官网建设流程全解析

刚接手新项目时，我翻了一版老站点，发现里面大批商品图都是直接丢一张 1920 宽的 JPG，缩略图、轮播图、详情大图全用同一张。用户在千元档手机上打开页面，体验倒还行——反正屏幕小，网速也撑得住。可一到 Retina 屏的 MacBook 上，缩略图糊得没法看；反过来，手机端首屏因为这张 1920 的图，加载慢得让人想骂人。

这就是响应式图片的典型困境。今天想跟你聊的，是把srcset与picture这两个看似基础的能力，真正沉淀成一套工程化实践的完整过程。它们不是让你手忙脚乱拼接的一堆属性，而是可以通过合理的产物链路、组件封装和调试验证，让浏览器自己去挑最合适的那张图。本文适合每周都要碰图片性能的前端工程师，也适合正打算改造公司图片方案的负责人，我会把原理、算法、落地链路和踩过的坑全部展开。

1. 一张图片的双重困境：显示精度与网络代价

1.1 同一张图，在不同设备上完全是两个需求

不管是电商详情页、新闻配图，还是内容平台的封面，图片面对的设备环境差异极大。一台 iPhone 的逻辑宽度只有 375px，但屏幕物理像素是 750px、甚至 1170px；一台 27 寸显示器的逻辑宽度可能是 2560px，却可能只是 1 倍屏或 2 倍屏。你想让画面在所有这些屏幕上看起来都清晰，就得准备不止一份资源。

很多早年间的方案是“取最大公约数”——直接全站加载 1600w 的图，然后把宽度交给 CSS 压缩。结果是小屏设备浪费了绝大多数流量，大屏设备在高倍屏下依旧不够锐利。开发者往往会陷入一个错觉：反正我压缩到合理体积了，网上也不差这点加载时间。但真实移动网络下，Lighthouse 的 Largest Contentful Paint 指标几百分的差距，往往就是这一堆没做过响应式处理的图片拖出来的。

1.2 图片体积守恒定律：清晰度越强，浪费越夸张

对一张 1600px 宽的 JPEG 商品图来说，在移动端只有 320px 宽的展示位，加载它依然要吞掉几十 KB 乃至上百 KB。如果首页有十几张这样规格的图，移动端流量成本和首屏延时就是成倍放大。可如果只准备小尺寸图呢？桌面自适应放大就会变糊。

这可能就是响应式图片要解决的核心矛盾：分辨率不能满屏跑，显示位有多宽、屏幕密度有多高，就应该让浏览器拿到恰好满足需求的图片。srcset和picture就是浏览器原生提供给我们的两套工具，互相补充、各司其职。前者解决“同一张图怎么按密度挑分辨率”，后者解决“不同场景怎么换内容换格式”。

1.3 工程化，不是把这些标签写进 HTML 就完事

真实业务里，商品图数量动辄几十万张，靠设计师手动导图不可能，靠前端手写 srcset 更不可能。工程化意味着从设计稿输出规范、构建流水线、前端组件封装到运行时验证，是一条完整的链路。我会在本文第 4 节重点展开这条流水线，这里先把两个 HTML 能力的原理吃透，因为不理解底层逻辑，后面你连调试都不知道从哪下手。

2. 理解 srcset 的选图机制，浏览器其实在替你做决策

2.1 最基础的 x 描述符，只做“屏幕密度匹配”

srcset最直觉的用法是配合x描述符，来表示这张图适合几倍屏。写法很直观：

<img src="photo-1x.jpg" srcset="photo-1x.jpg 1x, photo-2x.jpg 2x, photo-3x.jpg 3x" alt="示例图片">

浏览器拿到设备像素比（DPR）后，从候选里挑一个最接近的。1x 屏加载photo-1x.jpg，2x 屏加载photo-2x.jpg，很好理解。麻烦在于，它完全没考虑图片在页面里实际渲染多大。

如果你的 CSS 里把这张图片最终显示成宽度 640px，那么一个 2x 的 Retina 屏幕其实需要一张接近 1280px 宽的图片，但 2x 描述符里的候选图如果是 1000w，浏览器并不会知道你 CSS 里把它缩小了多少——因为x描述符只描述图片本身适配的密度，不参与布局宽度计算。所以 x 描述符适合“图片渲染宽度基本固定”的场景，比如头像、Logo、固定尺寸的缩略图。真正面向响应式布局，还得靠 w 描述符。

2.2 w 描述符和 sizes，是浏览器的最优解算法

w描述符不再说“我适合几倍屏”，而是直接告诉浏览器“我这张图实际宽度为多少像素”：

<img srcset="photo-480w.jpg 480w, photo-960w.jpg 960w, photo-1600w.jpg 1600w" sizes="(min-width: 1024px) 50vw, 100vw" alt="示例图片" >

w描述符里的 480w 代表这张图片的宽度是 480px。sizes告诉浏览器在不同媒体条件下，图片在布局里的真实渲染宽度。这一步是关键：浏览器无法直接读取你的 CSS 布局结果，它需要通过sizes来猜测图片在视口里的实际宽度，再结合候选图的物理宽度，算出这张图对当前屏幕而言的“有效密度”，最终选出最合适的来源。

我在实际项目里给sizes的定义一般是这样：

/* 当视口大于 1024px 时，图片占据约一半视口宽度；移动端占满整个视口宽度 */ sizes="(min-width: 1024px) 50vw, 100vw"

2.3 浏览器内部的选图数学题

假设你的设备视口宽度是 375px，DPR 是 2，那么浏览器希望找到一张图片，其物理宽度约等于“渲染宽度 × DPR”。计算过程大致是这样：

1. 当前视口宽度 375px，DPR=2，目标图片宽度是375 * 2 = 750px；
2. 根据sizes规则，如果当前是移动端，渲染宽度约等于视口宽度 375px，那么候选480w图片的有效密度是480 / 375 = 1.28，960w的有效密度是960 / 375 = 2.56，1600w是1600 / 375 = 4.27；
3. 浏览器选密度最靠近 2 的候选，于是960w胜出。

这个“有效密度”的计算思路，解释了为什么 w 描述符必须搭配 sizes 才能发挥最大价值。没有sizes时，浏览器默认把图片当成100vw即满屏宽度来算，这在小屏设备上会严重高估图片的显示需求，导致选了过大的图。很多人在本地测试时看不出差别，就是因为开发时通常在全宽窗口里切设备模拟，页面宽度和视口宽度基本一致。

2.4 省流量模式下浏览器还会“作弊”

这里有个容易忽略的点：浏览器的选图算法并不是只盯 DPR。很多浏览器在用户开启“数据节省”或系统低电量模式时，会调低资源的密度偏好，甚至刻意跳过最清晰的候选图。

意思是，同一个页面、同一套 srcset，在不同设备设置下，浏览器真的可能选到完全不同的资源。这既是优点也是坑：你无法笃定线上一定加载某张图，也不能用“本地模拟 DPR 后加载了 A 图”来推断所有用户都会加载 A 图。正确的工程姿势是后面要讲的：基于候选集合做工整的降级策略，而不是替浏览器把决策写死。

3. picture 存在的理由：改内容，而不只是换分辨率

3.1 艺术指导场景：宽屏和竖屏需要的是不同构图

srcset再怎么灵活，也只能在“同一张图像内容”的前提下换分辨率。现实业务里经常碰到另一种需求：同一个产品位，桌面端想展示横版全景，移动端想展示居中放大的细节图。这两张图已经不只是大小不同，而是构图都变了。这种场景就该上picture：

<picture> <source media="(min-width: 1024px)" srcset="hero-desktop.jpg"> <source media="(min-width: 640px)" srcset="hero-tablet.jpg"> <img src="hero-mobile.jpg" alt="横版与竖版构图示例"> </picture>

source按顺序匹配media条件，第一个满足条件的会被使用。注意最后一个img标签不仅是兜底，它本质上就是正常图片；picture只是包在外面的一组“来源选择器”，浏览器最终渲染的还是img。

我在项目里见过不少人把这个能力用错：把media断点写得和 CSS 断点不一致，结果桌面端显示的是移动端图、移动端拉的是超清大图。这里我建议把 picture 的断点与产品规范里的断点表统一成一个常量文件，人和 CSS 都不要出现魔法数字。

3.2 用 type 属性做格式升级降级，而不是靠 UA 判断

picture另一个杀手级场景是通过<source type>让浏览器自己选择可解码的图片格式。比如 AVIF 体积比 JPEG 小一大截，但老浏览器不支持；你可以这样写：

<picture> <source type="image/avif" srcset="photo.avif"> <source type="image/webp" srcset="photo.webp"> <img src="photo.jpg" alt="格式降级示例"> </picture>

浏览器会按顺序检查type是不是支持的 MIME，第一个认识的就选，全都不认识就落到img src。不用写任何 UA 判断代码，比 JavaScript 检测干净得多。配合第 4 节讲的工程化流水线，格式降级几乎是零成本的。

3.3 picture 与 srcset 不冲突，甚至可以叠着用

很多人以为picture是用来取代srcset的，其实它们是配合关系。source标签里同样可以写srcset，让媒体条件匹配后，再按 DPR 和视口宽度挑更细的资源：

<picture> <source media="(min-width: 1024px)" srcset="hero-1600w.jpg 1600w, hero-2400w.jpg 2400w" sizes="50vw"> <source media="(min-width: 640px)" srcset="hero-960w.jpg 960w, hero-1280w.jpg 1280w" sizes="80vw"> <img src="hero-mobile.jpg" alt="组合使用示例"> </picture>

工程中应该遵循的原则是：先用 picture 解决“内容要不要换”的问题，再在命中的 source 上用 srcset 解决“分辨率选哪档”的问题。

4. 把 srcset 扩进流水线：图片交付的工程化设计

4.1 从设计稿到多尺寸产物：先定一套命名规范

响应式图片工程化的起点从来不是写标签，而是定产物规范。我参与过的项目统一采用<width>w作为文件名后缀，例如：

product-hero-480w.jpg product-hero-960w.jpg product-hero-1600w.jpg product-hero-2400w.jpg

同时保留一份原始无损 PNG 或 TIFF 放在原始资源目录，后续加尺寸、重新压缩都有底稿可循。代码里不要生成 “product-hero-1x.jpg” 这种密度命名加宽度混用的方式，后面脚本解析时会非常痛苦。

4.2 一套基于构建脚本的自动裁剪与压缩链路

最朴素的做法是构建时用 Node 脚本批量处理。我用过sharp，它速度快、支持格式广，非常适合做图片流水线。下面是一个裁剪脚本的关键逻辑：

const sharp = require('sharp'); const path = require('path'); async function resizeImage(inputPath, outputDir, widths) { for (const width of widths) { const outputPath = path.join(outputDir, `product-${width}w.jpg`); await sharp(inputPath) .resize({ width, withoutEnlargement: true }) .jpeg({ quality: 78, mozjpeg: true }) .toFile(outputPath); } } // 用法示例 resizeImage('source/product.png', 'dist/images', [480, 960, 1600, 2400]);

脚本需要关注两个关键点：一是withoutEnlargement: true防止把小图强行放大成大图，污染产物；二是 JPEG 压缩用mozjpeg编码或等价的压缩库，可以在肉眼感知差异极小的情况下省出 20% 到 30% 的体积。AVIF 生产环境现在也值得开，sharp支持直接把同一张源图同时输出为.avif和.webp给 type 降级链路用：

await sharp(inputPath) .resize({ width: 1600 }) .avif({ quality: 45 }) .toFile('dist/images/product-hero-1600w.avif');

改完脚本以后，构建产物目录长这样：

dist/images/ product-hero-480w.jpg product-hero-960w.jpg product-hero-1600w.jpg product-hero-2400w.jpg product-hero-960w.avif product-hero-1600w.avif ...

4.3 组件封装：业务侧永远不该手动拼 srcset

工程化的核心是让业务侧没有机会犯错。我习惯把图片资源地址、宽度列表、格式列表全部封装进一个组件里。以 React 为例，一个极简的响应式图片组件可以这样设计：

// ResponsiveImage.jsx import React from 'react'; export default function ResponsiveImage({ baseUrl, widths, sizes, alt, className }) { const srcset = widths.map(w => `${baseUrl}-${w}w.jpg ${w}w`).join(', '); return ( <picture> <source type="image/avif" srcSet={widths.map(w => `${baseUrl}-${w}w.avif ${w}w`).join(', ')} sizes={sizes} /> <source type="image/webp" srcSet={widths.map(w => `${baseUrl}-${w}w.webp ${w}w`).join(', ')} sizes={sizes} /> <img src={`${baseUrl}-${widths[0]}w.jpg`} srcSet={srcset} sizes={sizes} alt={alt} className={className} loading="lazy" /> </picture> ); } // 调用侧只需关注业务意图 <ResponsiveImage baseUrl="/images/product-hero" widths={[480, 960, 1600, 2400]} sizes="(min-width: 1024px) 50vw, 100vw" alt="商品图" />

这个组件把三个容易出错的位置全收敛了：

• URL 后缀规则只有组件内部知道；
• sizes有默认值，业务侧不传也不至于默认 100vw 造成浪费；
• srcset串由宽度表自动生成，不会出现 480w 之后接 640w 这种遗漏。

Vue 里对应的思路完全一致，核心就是把widths、sizes、baseUrl当输入，渲染逻辑收敛在单个组件里。后端 SSR 或者模板引擎场景，也可以直接复用同样的 HTML 生成逻辑，只要保证产物 URL 拼接规则一致即可。

4.4 动态图片服务与本地构建的取舍

另一个方向是图片服务动态裁剪。像各类 CDN 图片处理服务，你给一张原图 URL，加上?w=480&q=78之类的参数，它会实时返回裁剪结果。这套方案的优点是开发期零构建成本，业务侧随便写尺寸参数，特别适合内容运营需要不定期生成新尺寸的场景。

但工程上要注意两点：一是动态裁剪服务通常按字节数和请求次数计费，线上图片流量大的话成本会越滚越高；二是源图一旦出现超大文件，参数裁剪造成的 CPU 开销也会转移给服务商，响应时间往往比你预想得更不稳定。我的建议是：小团队、运营驱动的内容站优先上 CDN 动态裁剪；对性能要求严苛的大流量核心链路，还是回到构建产物 + 对象存储的静态方案。两种方案在组件层可以做到完全无感，因为你的组件只需要传入baseUrl和widths，srcset生成逻辑可以要么拼 URL 要么拼文件路径。

5. 生产环境里实测出来的几个隐藏干扰项

5.1 浏览器缓存会让你的选图逻辑“看起来很灵”

很多人在开发者工具里模拟不同 DPR，按 F5 刷新，发现图片一直加载的是同一张，便怀疑 srcset 失效了。其实这多半是缓存问题。浏览器一旦把某张资源放进缓存，同一 URL 就会直接命中，不会再走srcset的选图逻辑。调试时务必打开 DevTools 的 “Disable cache” 选项，并且把 Network 面板按图片类型过滤，确认实际落地的资源 URL。

如果线上出现“同一分辨率下某些用户加载了大图”，先别急着怀疑算法。看看那张大图 URL 是否同时出现在页面其他位置，或者是否被 Service Worker 预缓存过，这些情况都会绕过 srcset 选择。我排查过的一次线上问题，最终原因就是 PWA 的 Service Worker 在安装阶段把所有中等尺寸图片预缓存，导致浏览器认为缓存资源可用，不再去加载高密度尺寸。

5.2 sizes 写错，比不写还浪费

sizes最大的隐藏风险不是写错断点，而是写错百分比。比如你在宽度为 375px 的手机上渲染一张占屏幕 90% 的图片，却把 sizes 写成了90vw。看起来没问题，对吧？但浏览器再乘以 DPR 时，目标图片宽度会偏小，可能只选择了 480w 的图，在 2x 屏上仍然有点糊；反方向写太大，则会白下载一张本不需要的高清图。

最稳妥的做法是交给 CSS 本身？不行，因为 HTML 解析阶段浏览器还没执行 CSS 布局。所以必须明确一个原则：sizes 描述的是布局宽度，一旦 CSS 改动导致图片实际呈现宽度变化，就要同步更新 sizes。我在长期维护的项目里，会把所有图片布局场景整理成一个表格：

5.3 视觉回归测试和资源加载量是两套指标

视觉回归工具（无论是自己做截图比对还是用现成的快照工具）默认比较的是渲染后的页面截图，你很容易看到“图片显示宽度正确”就结束验收。但性能上真正要看的，是页面在当前视口和 DPR 下实际下载了多少字节。这两件事经常有一项踩坑。

我在改造一批老页面时，把图片全部替换成响应式版本，视觉截图比对全绿，但看 Performance 面板才意识到有几张sizes没更新的图片依旧下载了 1600w 的大图。从那以后，凡是和图片性能相关的迭代，我都会在验收清单里加一条“用低速网络模拟 3G，检查 Network 面板图片请求大小分布”，而不是只盯着样式的像素级还原。

5.4 服务器端渲染和 hydration 时的 srcset 拼接差异

如果你的站点是 SSR 或静态生成，注意组件在服务端拼出的srcset串应该和客户端完全一致，否则水合阶段会出现一份属性对不上的警告，或者发生资源的二次加载。这个问题的典型来源是：组件里依赖了window或运行时环境来做拼接。解决方式是保证sizes、widths通过 props 传入，服务端渲染和浏览器端复用的纯函数输出完全相同的字符串。

服务端渲染还有一个延迟坑：如果服务端用picture+type生成多个<source>，但你的图片对象存储在上传后就固定了扩展名，那么新增 AVIF 版本时必须确保静态资源发布先于页面代码上线，否则 HTML 会引用一个还没上传的.avif文件，浏览器在降级到.jpg之前会先得到 404。这块要用发布流程控制，不能只靠代码。

6. 兼容老浏览器与新格式：一条渐进增强路线

6.1 现代浏览器已经不需要 polyfill，但要读懂兜底

srcset和picture在现代浏览器里的支持度已经相当好了。老版本 Safari 不认picture时，会因为不认识这个标签而直接忽略内部的<source>？不会，它会把picture当成一个普通的未知元素，然后正常渲染内部的<img>，所以兜底链路天然成立。

如果你还需要支持很老的 IE11 时代的浏览器，可以考虑在构建时引入一段极小的 polyfill，但现代项目里我更推荐干脆放弃——给老浏览器固定加载img src上的中等尺寸图即可，页面功能不受影响，只是清晰度略低。这是渐进增强的自然结果，用户感知不明显，业务风险小。

6.2 懒加载、预加载与响应式图片的排兵布阵

响应式图片搭配懒加载要注意一个关键顺序：loading="lazy"会让浏览器在图片进入视口附近时才去解析 srcset，而对应的高度预留如果在 CSS 里不稳定，实际渲染宽度会被视口宽度干扰，导致选图偏差。因此首屏关键图片慎用 lazy，可以用在滚动较深的列表和详情大图上；首屏图用默认立即加载即可。

对极少数关键首屏大图，还可以用fetchpriority="high"主动提升加载权重。但别把一屏里的所有图都标成 high，浏览器会忽略你的重点，甚至因并发争抢拖慢首屏。只对真正理解为核心的图片出手，其余交给默认的加载优先级。

6.3 AVIF 已在路上，产物链路要提前预留

AVIF 压缩率优于 WebP，同样的视觉效果能再省不少体积。当前主流浏览器均已支持，工程链路里最值得做的就是给它留好位置。按照第 4 节的组件设计，几行代码就能并行输出三种格式并让浏览器自动降级。我个人的建议是：已经把图片流水线搭成构建脚本的团队，在上新图时就将 AVIF 纳入默认产物；历史存量图可以按访问热度逐步补齐，不要一次性全量重转，否则构建时长和存储都吃紧。

现在回头看，响应式图片从来不是一个标签的语法问题，而是一条从设计稿尺寸规范、构建产物策略、组件封装，到线上性能验收的完整链路。我接手的多个项目里，单是把sizes与实际布局对齐并瘦身产物大小，移动端图片字节总量往往能下降一半以上，这个收益直接体现在加载时长上。如果你正准备改造图片方案，我的建议是先选定一种图片交付方式，再把组件和 build 脚本串起来，不用追求一次到位，先把首屏核心图跑通、用 DevTools 验证真实下载量，再逐步铺开。