企业官网建设流程全解析

现在打开任何一个电商详情页或者资讯站点，随手看几眼<img>标签，你会惊讶地发现真正把图像大小写对的人其实不多——要么是原图 2000px 硬塞进 320px 的卡片里，要么是只写了一个width导致整块布局被撑歪，还有更常见的：图片在移动端糊成一团马赛克。在 HTML 里调整图像大小，表面上看就是把数字改小，实际上它牵扯到显示尺寸、固有尺寸、像素密度、响应式断点、布局稳定性这一整条链路。这篇内容我打算把自己这几年在真实项目里处理图片尺寸的经验完整摊开讲，从最基础的width/height属性，到 CSS 的object-fit、aspect-ratio，再到srcset/sizes响应式方案，最后是那些只有踩过坑才知道的排查技巧。不管你是刚学 HTML 的新手，还是已经在写页面的前端，都能从中找到能直接抄走用的方案。

1. 图像尺寸这件事，先搞清楚三个概念

很多人调不好图片尺寸，根本原因不是不会写代码，而是脑子里混淆了几个"尺寸"。这几个概念不掰清楚，后面所有操作都是瞎猜。

1.1 显示尺寸、固有尺寸与像素密度

固有尺寸（intrinsic size）是图片文件自带的像素宽高，比如一张 1200×800 的 JPG，它的固有尺寸就是 1200 像素宽、800 像素高。这个值写在文件头里，浏览器加载完（或者拿到元数据后）就知道。显示尺寸（display size）是你在页面上让它占多大地方，由 HTML 属性或 CSS 决定。两者的关系决定了图片是否会被缩放：显示尺寸小于固有尺寸是缩小，通常更清晰；显示尺寸大于固有尺寸是放大，几乎一定发虚。

真正容易忽略的是第三个概念——设备像素密度（DPR）。一台标称 375 CSS 像素宽的收集，如果 DPR 是 2，它实际有 750 个物理像素点。也就是说，一张在 CSS 里显示为 375px 宽的图片，要铺满屏幕的物理像素，源文件至少得有 750px 宽才不会糊。这就是为什么同样一张图，在电脑上看很锐利，换到手机上就发软——电脑 DPR 通常是 1，手机是 2 甚至 3。

我习惯用一个简单的心算公式来估算最小可用源宽：

所需最小源宽 = CSS 显示宽度 × 目标 DPR

比如卡片在桌面端显示 320px、DPR 为 2，那源图至少要 640px 宽。低于这个数，放大就是自找模糊。

1.2 为什么直接写 width/height 容易被吐槽

HTML 提供了width和height两个属性，这是最原始也最直接的调整方式：

<img src="cover.jpg" width="400" height="300" alt="封面图">

这种写法本身没错，甚至在防止布局抖动这件事上，它还比纯 CSS 更受推荐。它被吐槽的原因主要是两个。

第一个原因是写死了尺寸。width="400"就是 400 像素，容器变窄时图片不会跟着缩，直接溢出或者把父元素顶开，手机上就会看到横向滚动条。第二个原因是单位本质是 CSS 像素，不是源文件像素——很多人以为写了width="400"就是把源图缩到 400，其实源图该多大还多大，压缩体积这件事它一点忙都帮不上。

所以正确的态度是：width/height属性该写，但要理解它只是在告诉浏览器"这块地我要占这么大"，至于缩放的细节和响应式，交给 CSS 补。

1.3 调整大小的两条主线：属性控制与 CSS 控制

实际项目里，图像大小永远是两条线配合着用。

一条是结构线，用 HTML 属性把图片的宽高"占位"声明出来，让浏览器在图片还没下载完的时候就预留好空间。这条线的核心价值是稳定布局，防止内容跳动（CLS 问题）。另一条是表现线，用 CSS 控制最终渲染出来的尺寸、裁剪方式和响应式行为。这条线才是真正决定"看起来多大"的。

两条线冲突的时候谁说了算？CSS 赢。因为 HTML 的width/height属性在规范里被归类为"呈现性提示"（presentational hints），优先级低于任何作者样式表里的规则。所以你会经常看到这种组合写法：

<img src="cover.jpg" width="1200" height="800" alt="封面图">

img { max-width: 100%; height: auto; }

属性里写的是原始宽高比（用来占位），CSS 负责把它压进容器里同时保持比例。这是目前公认最稳的一套起手式。

注意：width/height属性写原始像素值（比如 1200×800），不要写显示尺寸，否则响应式下比例会跟你想的对不上。

2. HTML 原生属性调整图像大小的正确姿势

先把最简单的部分讲透。很多人觉得属性没啥可说的，其实魔鬼全在细节里。

2.1 width 与 height 属性的写法规则

width和height是<img>的全局属性，接收一个正整数，单位是 CSS 像素。它们有两个作用：一是设定显示尺寸，二是给浏览器提供宽高比信息用于占位。这两个作用是有先后关系的——如果只写了一个，浏览器会用固有宽高比推算出另一个。

<!-- 写法一：两个都写，比例由你决定，可能与原图不一致 --> <img src="photo.jpg" width="600" height="600" alt="方形裁切"> <!-- 写法二：只写宽，高等比算出 --> <img src="photo.jpg" width="600" alt="等比缩放"> <!-- 写法三：写原始尺寸，配合CSS做响应式（推荐） --> <img src="photo.jpg" width="1600" height="900" alt="推荐写法">

写法一在需要强制方形时有用，但会让图片变形（后面会讲怎么用object-fit补救）。写法二看似省事，但有个隐患：如果图片因为网络问题没加载出来，或者你用的是懒加载，浏览器在拿到图之前不知道固有比例，就会按默认尺寸或 0 高度处理，布局照样跳。写法三是我现在默认采用的，属性写原图真实尺寸，CSS 负责缩放，占位和响应式都不耽误。

2.2 只写一个维度的后果与等比缩放规则

只写width不写height，浏览器会按图片自身的宽高比自动算高。这个"自动"依赖两个条件：浏览器能读到图片的固有宽高比，并且没有被 CSS 的height显式覆盖。

一旦你在 CSS 里写了height: 200px却没写width，情况就变了：图片会被拉伸成 200px 高、宽度按原比例算，但如果父容器有固定宽度约束，它可能被压扁。极端情况下，width: 100%; height: 300px;这样的组合会直接把图片拉变形——宽度跟着容器走，高度被钉死，宽高比彻底失控。

实操心得：只要你在 CSS 里给图片设置了固定高度，就一定要同时确认宽度逻辑，否则变形是必然的。如果需要"填满某个区域但不接受变形"，用object-fit，别硬改宽高。

2.3 属性与 CSS 冲突时的优先级验证

这个点我用一小段代码验证过，结论很确定。

<img src="photo.jpg" width="800" height="600" style="width: 200px;" alt="测试">

最终渲染宽度是 200px，不是 800px，高度则被等比缩到 150px（注意——不是 600px，因为只覆盖了宽度，浏览器按比例重算了高度）。这说明两件事：CSS 的width覆盖了属性width；CSS 没有设定的维度，浏览器仍然会借助宽高比推算。

再试一次，把 CSS 写成width: 200px; height: 100px;：

<img src="photo.jpg" width="800" height="600" style="width: 200px; height: 100px;" alt="测试">

这时候就是彻底的 200×100，比例被强行改变，图片变形。所以判断是否变形的标准很简单：最终生效的宽高比，和原图宽高比是否一致。不一致就是变形。

这张表我贴在手边很久了，调图的时候对着看一眼，基本能避免 90% 的变形问题。

3. CSS 调整图像大小的完整方案

属性解决的是"占位"，CSS 解决的才是"最终长什么样"。这一段是重点，我按使用频率从高到低排。

3.1 width/height 与 max-width:100% 的经典组合

如果只能记一条规则，记这个：

img { max-width: 100%; height: auto; }

max-width: 100%的意思是"图片最宽不超过父容器的宽度"，容器窄它就窄，容器宽它就保持原尺寸。注意是max-width而不是width——用width: 100%的话，一张 200px 的小图会被强行拉到跟容器一样宽，直接放大变糊。用max-width，小图保持原样，大图自动缩，这是最符合直觉的行为。

height: auto的作用是解除高度限制，让浏览器按宽高比重算高度。这两行合在一起，就构成了一个"永远不会溢出、永远不会变形、小图不放大"的默认状态。

如果确实需要小图也撑满容器（比如背景化的装饰条），那就用width: 100%; height: auto;，但要有心理准备，源图可能撑不住。

3.2 object-fit 五个取值的适用场景

当你既要固定尺寸，又不想变形时，object-fit就是答案。它决定图片内容在"内容框"里怎么摆放。前提是图片的宽高被显式设定（或者被aspect-ratio约束住），否则object-fit不起作用——这是新手最常见的困惑。

.card-img { width: 320px; height: 200px; object-fit: cover; }

五个取值的差异：

• fill：默认值，直接拉伸填满，比例不管，变形没商量。
• contain：完整显示整张图，多余空间留白，比例不乱。
• cover：填满整个框，超出部分裁掉，比例不乱，内容可能被切。
• none：保持原尺寸，不做任何缩放，超出的裁掉。
• scale-down：在none和contain里选更小的那个，效果上等于"只缩不放"。

我在实际项目里用得最多的是cover。原因很实际：列表页的卡片宽度各不相同（响应式），但视觉上要求图片高度统一，用cover加上固定高度，既能保证排列整齐，又不会把人物头像压成饼。唯一要注意的是裁切位置，默认从中心裁，主体偏一侧时会被切掉半张脸，这时候需要object-position配合，比如object-position: top center;把重点留在上半部分。

aspect-ratio是这几年的顺手工具：

.thumb { width: 100%; aspect-ratio: 16 / 9; object-fit: cover; }

它的好处是不用写死高度，宽度变高度自动按比例跟，配合object-fit: cover就是标准的"响应式固定比例裁切"方案。主流浏览器现在都支持，可以放心用。

3.3 防止布局抖动：宽高占位的老办法与新办法

图片在加载完成前高度是 0，加载完成后突然撑开，下方内容整体下移——这就是内容跳动，也是体验最差的性能问题之一。解决思路有两种。

老办法是给图片的父容器预留一个内边距撑出的比例空间，常见写法是：

.ratio-box { position: relative; padding-top: 56.25%; /* 9/16，对应16:9 */ } .ratio-box img { position: absolute; inset: 0; width: 100%; height: 100%; object-fit: cover; }

padding-top的百分比是相对父容器宽度计算的，所以56.25%就等价于 16:9 的高度。这个方法的原理稍微绕，但兼容性无敌。

新办法直接写aspect-ratio：

.ratio-box { aspect-ratio: 16 / 9; } .ratio-box img { width: 100%; height: 100%; object-fit: cover; }

两行搞定，代码干净。我个人现在的选择是：新项目一律用aspect-ratio，需要兼容很老的设备时才退回到 padding 方案。另外别忘了在<img>上老老实实写width和height属性，这是成本最低的占位手段，浏览器会据此算出默认宽高比。

3.4 用 background-size 处理装饰性图片

有些图片在语义上是"装饰"，比如按钮背景、Banner 底图、卡片角落的花纹，这类图用 CSS 背景图比<img>更合适，因为它不参与内容语义（屏幕阅读器不会读它），也不需要alt。

.banner { width: 100%; height: 320px; background-image: url('banner.jpg'); background-size: cover; background-position: center; background-repeat: no-repeat; }

background-size的常用值：

• cover：铺满容器，超出裁掉，比例不变，和object-fit: cover一个逻辑。
• contain：完整显示，可能留白。
• 100% 100%：强行拉伸到容器大小，会变形，一般只用在纯色纹理上。
• 100% auto/auto 100%：一个维度撑满，另一个按比例，等价于等比缩放。

注意：背景图如果包含有意义的信息（比如活动主视觉里的文字），不要用 background 写，因为它在语义上不可访问。该用<img>加alt。

还有一个差别要记住：background-size: cover在小屏幕上如果容器特别窄，裁切会变得非常狠，主体可能整个被切掉。所以 Banner 这类图我更倾向于给它配一个min-height，或者干脆用<picture>做艺术方向切换，而不是让cover无脑裁。

4. 响应式图片：让不同屏幕拿到不同尺寸的图

前面讲的缩放都是"同一张图在不同容器里显示不同大小"，但源文件始终是那一张。真正的响应式是让浏览器按屏幕条件去挑源文件，这一步靠srcset和sizes完成。

4.1 srcset + sizes 的工作机制与计算过程

先看一段完整代码：

<img src="photo-800.jpg" srcset="photo-480.jpg 480w, photo-800.jpg 800w, photo-1200.jpg 1200w, photo-1600.jpg 1600w" sizes="(max-width: 600px) 100vw, (max-width: 1000px) 50vw, 800px" width="1600" height="900" alt="示例图">

srcset里的480w、800w叫宽度描述符，告诉浏览器"这个文件实际是 480 像素宽"。注意单位是w不是px，这是媒体条件专用的写法。

sizes是在告诉浏览器"在不同屏幕条件下，这张图会显示多宽"。100vw表示占屏幕宽度的 100%，50vw是一半，800px是固定值。

浏览器挑图的逻辑是：先按当前视口匹配sizes得出槽位宽度，再乘以当前 DPR 得到所需像素宽度，最后从srcset里选一个不小于该值、且最接近的文件。举一个具体例子你会更清楚：

假设视口宽 375px、DPR 为 2、sizes匹配到100vw，那么槽位宽度是 375px，所需像素宽度是 375 × 2 = 750px。srcset里有 480w、800w、1200w、1600w，大于等于 750 的最小值是 800w，所以浏览器挑photo-800.jpg。如果换成视口 1440px、DPR 为 1、sizes匹配到800px，所需 800px，同样挑 800w 那张。

如果sizes没写呢？默认值是100vw。这就是很多页面手机端加载了桌面大图的原因——srcset写了，但sizes漏了，浏览器按满屏宽度去算，自然挑最大的。

实操心得：sizes里的媒体条件顺序很重要，是从上往下匹配，命中即停。所以窄屏条件必须写在前面，写成(max-width: 1000px)在(max-width: 600px)之前，那 600px 这条就永远命中不了。

4.2 picture 元素与艺术方向切换

srcset解决的是同一张图的多个分辨率，<picture>解决的是构图本身要变。比如桌面端是横构图大图，手机端希望换成竖构图紧凑版，这种叫艺术方向切换，srcset做不到，得用<picture>：

<picture> <source media="(max-width: 600px)" srcset="hero-mobile.avif" type="image/avif"> <source media="(max-width: 600px)" srcset="hero-mobile.jpg"> <source media="(min-width: 601px)" srcset="hero-wide.avif" type="image/avif"> <source media="(min-width: 601px)" srcset="hero-wide.jpg"> <img src="hero-wide.jpg" width="1600" height="600" alt="横幅图"> </picture>

<picture>的工作方式是自上而下找第一个media匹配、同时type也被支持的<source>，命中就停。最后的<img>是必需的兜底，也是唯一能加alt和width/height的地方——别漏了它。

格式降级（AVIF → WebP → JPEG）就靠type属性实现，还是同一套逻辑。这个用法在图片体积优化上收益非常明显，AVIF 通常比同质量的 JPEG 小 40%~50%。

4.3 DPR 与 2x/3x 图的取舍

除了w描述符，srcset也支持x描述符，语法是photo.jpg 2x，用于固定 DPR 场景。比如一个固定 100px 宽的 Logo：

<img src="logo.png" srcset="logo.png 1x, logo@2x.png 2x, logo@3x.png 3x" width="100" height="100" alt="Logo">

这种写法适合尺寸固定的元素，浏览器直接用 DPR 匹配。但它不会考虑容器宽度变化，所以不适合内容图。

关于 2x、3x 图要不要都做，我的看法是：按实际收益来。3x 图体积大、收益相对 2x 提升有限，如果站点用户里高 DPR 设备占比不低，源图做到够用即可，盲目做 3x 往往会拖慢加载。我的做法是准备 1x 和 2x 两套，同时用现代格式压体积，性价比最高。

5. 实操：三种典型场景的完整落地方案

概念讲完，来点能直接抄的。下面三个场景覆盖了日常 80% 的图片尺寸需求。

5.1 场景一：文章正文里的插图

正文插图的特点是宽度跟随内容区，高度不定，可能有横图也可能有竖图。

<figure> <img src="inline-1200.jpg" srcset="inline-600.jpg 600w, inline-1200.jpg 1200w" sizes="(max-width: 760px) 100vw, 720px" width="1200" height="800" loading="lazy" decoding="async" alt="正文插图示例"> <figcaption>图 1：插图说明</figcaption> </figure>

figure img { max-width: 100%; height: auto; display: block; border-radius: 6px; }

这里几个细节值得说。display: block是为了消除行内元素底部的那条基线间隙，否则图片下方会多出 3~5px 的空白，跟文字排版时特别明显。loading="lazy"让首屏之外的图延后加载，正文长文提升明显。decoding="async"让图片解码不阻塞渲染主线程。

注意：首屏内的图片不要加loading="lazy"，会延迟它的加载，反而变慢。首屏的 Logo、主视觉这类关键图，反而应该考虑加fetchpriority="high"。

5.2 场景二：固定比例的商品卡片

电商卡片要求所有图片高度一致、比例一致，否则列表看起来乱。

<a class="card" href="/item/1"> <div class="card-media"> <img src="item-800.jpg" srcset="item-400.jpg 400w, item-800.jpg 800w, item-1200.jpg 1200w" sizes="(max-width: 600px) 50vw, 260px" width="1200" height="1200" loading="lazy" alt="商品图"> </div> <h3>商品名称</h3> </a>

.card-media { width: 100%; aspect-ratio: 1 / 1; overflow: hidden; background: #f5f5f5; } .card-media img { width: 100%; height: 100%; object-fit: cover; display: block; }

aspect-ratio: 1 / 1保证容器永远正方形，object-fit: cover保证图片填满且不变形，background: #f5f5f5是加载期间的中性占位色，避免白洞。这套组合基本是电商卡片的标准答案。

有个细节：sizes里写的是260px而不是卡片宽度百分比，因为桌面端卡片宽度是固定的。如果卡片本身也是弹性的，那就改成对应的vw值。这一步写不准，srcset的收益会打折。

5.3 场景三：全屏 Banner 与移动端适配

Banner 的难点是宽高比跨度大——桌面可能是 1920×600，手机是 750×900，构图完全不同。这时候srcset的等比缩放就不够了，得上<picture>。

<picture class="hero"> <source media="(max-width: 600px)" srcset="hero-s.avif" type="image/avif"> <source media="(max-width: 600px)" srcset="hero-s.jpg"> <source srcset="hero-l.avif" type="image/avif"> <img src="hero-l.jpg" width="1920" height="600" fetchpriority="high" alt="主视觉"> </picture>

.hero, .hero img { display: block; width: 100%; } .hero img { height: auto; max-height: 600px; object-fit: cover; object-position: center 30%; }

object-position: center 30%是我踩过坑之后加上的。Banner 图里的人物通常在画面上三分之一，默认从中心裁会把头切掉，把纵向锚点调到 30% 左右，主体就保住了。

5.4 上线前的图片尺寸自检清单

每次上线前我会走一遍这个清单，五条不多，但能挡掉大部分事故。

6. 常见问题与排查技巧实录

这一段全是实战里攒下来的，文档里基本不会写。

6.1 图片模糊、锯齿、变形的成因对照

模糊和变形是两码事，排查方向完全不同。

关于"大幅缩小有锯齿"这条，我做个补充：把 4000px 的图直接缩到 100px，浏览器采样算法可能有轻微噪点。稳妥做法是导出时就按目标尺寸的两倍准备（比如显示 100px 就导出 200px），而不是让 4000px 硬缩到 100px。这一步在构建流程里加个图片处理步骤就能自动完成。

6.2 图片不显示、只显示一半的排查顺序

遇到"图片不见了"或者"只有一条边"，我一般按这个顺序查：

1. 打开开发者工具，看<img>的渲染盒尺寸。如果宽或高是 0，说明尺寸被某个 CSS 规则压掉了，常见元凶是父容器的display: flex加align-items: stretch导致的尺寸塌陷。
2. 看object-fit是否被设置了但宽高没设。object-fit在没有显式尺寸时基本不生效，表现上像是图片"没变化"。
3. 检查父容器有没有overflow: hidden加固定高度，这会把图片直接裁掉大半。
4. 看是不是aspect-ratio和固定height同时存在，两者打架时高度会被固定值接管。
5. 最后才怀疑路径和格式问题，因为前四条出问题的概率高得多。

踩坑记录：我曾经花半小时查一张"显示不全"的图，最后发现是父级line-height和vertical-align组合导致的基线偏移配合overflow: hidden裁切。行内图片的排版行为比想象中复杂，加display: block能规避一大类问题。

6.3 布局抖动与图片占位的稳定方案

内容抖动（CLS）的根源永远是"图片撑开时没有预留空间"。三个层次的解决方案，按成本从低到高：

第一层，给每个<img>补上width和height属性，写原图真实尺寸。浏览器会据此算出宽高比，在图片没下载完时就预留好正确比例的空间。这一层几乎零成本，收益最大，别跳过。

第二层，给图片容器加aspect-ratio或者 padding 比例盒，把比例再明确一次。这一层主要应对"容器比例和图片比例不一致"的情况，比如卡片是 1:1 但图片是 4:3。

第三层，给容器加背景占位色或骨架屏。这一层是体验优化，让加载期间不是一片空白。

img { max-width: 100%; height: auto; background: #f0f0f0; }

给所有图片默认加个浅灰背景，是我一个很省事的习惯，加载期间能显示出一个灰色块，视觉上比纯白洞舒服得多，而且不会有额外布局成本。

6.4 几个只有实际项目才会遇到的问题

SVG 的尺寸处理跟位图不一样。SVG 是矢量，理论上无限放大不失真，但它也有固有尺寸。如果 SVG 文件里根元素写了width="24" height="24"，你在 CSS 里放大到 48px，浏览器会按 24 的比例放大，通常没问题；但如果只写了viewBox没写宽高，它在某些浏览器里可能按默认 300×150 渲染。稳妥做法是给 SVG 也显式设置 CSS 宽高：

.icon { width: 24px; height: 24px; display: block; }

邮件里的 HTML 是另一套规则。很多邮箱客户端对 CSS 支持极差，max-width、object-fit、srcset基本都不可靠。写邮件模板时，图片尺寸只能靠<img>的width/height属性硬编码，而且要按最窄的客户端宽度来定。这个限制挺让人难受，但确实没有更好的办法。

导出尺寸尽量用偶数。这个习惯来自一次排查：图片在某个尺寸下边缘出现半像素的灰线。原因是缩放后落在半像素边界上，抗锯齿产生了过渡色。把导出尺寸都改成偶数（比如 600 而不是 601），配合整数倍的显示尺寸，这类问题基本消失。

构建时压缩比运行时缩放划算得多。用 4000px 的原图让浏览器缩到 400px 显示，浪费的是用户的流量和时间。在构建阶段就把图片处理成几个目标尺寸（480/800/1200），再配合srcset分发，才是真正的解法。我通常用一套简单的脚本处理，输出时同时生成 WebP 和原格式，源图保留在仓库里不直接上线。

# 批量生成多个宽度版本（以 800 为例） magick input.jpg -resize 800x -strip -quality 82 output-800.jpg

-strip去掉 EXIF 元数据，能省下不少体积；-quality 82是 JPEG 的甜点值，再往上体积涨得快、肉眼收益却很小。这些小操作堆起来，一个页面的图片总重能降一半以上。

关于 HTML 里调整图像大小，我最后再分享一个自己的判断习惯：先问"这张图会变大还是变小"，再问"它会不会在加载时撑动布局"，两个问题回答完，该用哪套方案基本就定了。源图够大、固定尺寸不变形的场景，object-fit加aspect-ratio一把梭；宽度弹性的内容图，max-width: 100%加srcset是标配；构图需要换的，才值得上<picture>。别一上来就堆方案，大部分问题其实两行 CSS 就能解决。