一个宽度 390 像素的手机页面下载了 4000 像素原图，浏览器最后把它缩小显示。图片看起来正常，传输与解码成本却已经发生。响应式图片要解决的不是 CSS 能否缩放，而是服务器提供哪些候选资源，以及浏览器如何选择。
本文讨论公开博客的封面与正文插图。产品截图需要保留可读细节，不能套用风景图一样的强裁切策略；视觉资产的预算应依据读者任务决定。
sizes 描述布局，不是资源宽度
<img
src="/images/workspace-960.webp"
srcset="/images/workspace-480.webp 480w, /images/workspace-960.webp 960w, /images/workspace-1600.webp 1600w"
sizes="(max-width: 700px) 100vw, 70vw"
width="1600"
height="1000"
alt="桌面上的笔记本电脑与代码编辑器"
/>srcset 提供候选图，sizes 告诉浏览器图片预计显示多宽。上面的 70vw 只有在真实布局近似如此时才合适。如果图片位于固定最大宽度容器，应写出匹配的限制，不然浏览器可能选过大资源。
像素密度会影响选择，高密度屏幕需要更高分辨率才能清晰。不要期待每个手机都选择最小图，也不要用一次网络请求结果推断所有设备行为。浏览器可能复用已经缓存的较大资源，测试时要控制缓存。
假设文章容器最大宽度七百二十像素，手机两侧各留十六像素，桌面居中。手机上的显示宽度约为视口减三十二像素，宽屏上最多七百二十，而不是始终百分之七十视口。sizes 应表达这个约束，再为常见显示宽度和像素密度生成有限候选。候选越多并不必然更快，构建与存储成本也随变体数量增加。
若透明架构图在浅色背景可读、深色主题下连线消失，继续增加分辨率并不能修复。先查看图中的线条与文字是否依赖默认背景，再决定保留明确底色、生成主题变体还是使用受控可着色图形。主题变体若改变图例颜色，需要保持类别和标记一致；加载正确候选只证明资源选择正常，不证明信息仍可辨认。
技术截图与摄影图需要不同压缩判断。截图文字边缘在强压缩后可能模糊，照片则可能在较低质量下仍然满足用途。应使用代表性内容比较，而不是全站一个质量数值。代码图如果无法保持移动可读，可以转换为可复制代码块，图片只展示必要界面上下文。最有效的图片优化有时是改变信息呈现方式，而不是寻找更小格式。
稳定尺寸可以避免正文跳动
width 与 height 提供固有比例，CSS 可让图片响应式缩放。若用背景图，容器应有明确比例或高度约束。加载后才决定高度，会把标题和正文向下推，破坏阅读位置。
首屏真正关键的图片可以考虑较高加载优先级，屏幕下方插图使用懒加载。不要给所有图片都设置高优先级，资源竞争会反过来影响关键字体、CSS 和脚本；也不要让首屏主图懒加载后期待它及时出现。
裁切是信息设计的一部分
技术截图通常应该完整呈现重要区域。object-fit: cover 适合可裁切照片，却可能截掉代码行、坐标轴或关键按钮。如果截图文字太小，应提供可放大版本或重新截取关注区域，而不是让读者放大整个页面。
移动与桌面需要不同构图时，可以使用 picture 做艺术方向选择。替代文本描述图中与文章相关的信息，不应重复“这是一张图片”。如果图片只是装饰，应使用空 alt，避免屏幕阅读器朗读无关细节。
图片固有尺寸与 CSS 比例应一致。若桌面使用完整截图、手机使用裁切版本，两者可能具有不同宽高比，需要由 picture 或布局规则明确选择，避免图片加载后才调整比例。裁切前标记图中不可丢失的信息，例如错误提示、坐标轴和重要按钮。若这些区域在手机上被 cover 截掉，字节再小也没有完成文章任务。
替代文本应解释图像传达的关键结论。界面截图可以描述正在比较的状态，而不是罗列所有按钮。复杂架构图的完整说明放在附近正文，alt 提供概括并指向解释；不能把几百字塞进属性就认为可访问。装饰照片可以为空，但承担证据的技术图不能因为已有标题就直接省略信息。
加载失败测试保留图片尺寸，让页面不塌陷，同时读者能够通过文字继续理解。对于可点击放大图片，控件需要明确可访问名称与键盘操作。不能仅给图片绑定鼠标点击事件，让键盘用户无法查看细节。放大后的资源也有预算，不在首次访问时偷偷下载全部原图。
假设一张日志截图包含十行上下文，其中真正讨论的是第三行错误。方案一保留完整截图，适合解释前后状态；方案二裁切到错误附近，适合手机快速定位；方案三把日志转成代码块并保留截图链接，适合复制和搜索。没有一个方案在所有场景中最好，需要由文章论证决定哪些信息必须同时可见。
比较时让读者完成同一任务，例如指出错误原因或找到某个按钮，而不是问哪张图更漂亮。合成可用性测试可以发现小字、裁切和放大控件问题，但不能虚构真实研究结果。记录测试条件和观察，不把少量内部试用包装成普遍结论。图片清晰度应以任务成功为依据，字节预算只是其中一个约束。
如果选择完整截图，可在正文解释关注区域并提供可放大原图；如果选择裁切，说明已省略哪些上下文；如果转成代码，保持文本与截图一致。修改文章后同步检查图中的版本、路径和标识，旧截图可能仍展示已经不推荐的配置。图片作为技术证据也有内容生命周期，不是上传完成就无需维护。
文件命名和替代信息应支持维护。采用有意义的资源标识，记录源文件和生成变体，不让作者手工修改几十个压缩文件。删除文章时确认图片是否仍被其他文章引用，不能凭目录位置直接移除共享资产。构建工具可以生成引用关系，帮助发现孤立文件和缺失资源，但来源许可仍需要人工记录。
最后审查首页重复图片的成本。列表缩略图不需要与详情页主图下载同样大小，多个缩略图同时进入视口时更要限制资源。复用原图方便作者，却可能让一个文章索引页比全部正文还重。给每种展示用途定义合适尺寸和加载策略，响应式图片预算才从单张图优化变成完整阅读体验的约束。
首屏优先级要基于真实关键元素
首页主图可能是最大的内容元素，文章页最大的内容元素却可能是标题或正文。不要因为一张图排在最上面就给所有图片高优先级。测量具体页面的加载过程，确认关键资源争用情况。首屏图若使用懒加载，浏览器可能在布局后才发起请求；反过来，所有图都立即加载则可能延迟关键样式与正文所需资源。
预加载也要准确匹配实际候选，否则浏览器先下载预加载文件，再根据 srcset 下载另一文件，反而浪费。使用平台或框架支持的响应式预加载能力时，检查最终请求，而不是只确认标签存在。过度预加载还可能下载用户不会看到的资源，特别是移动与桌面构图分别存在时。
正文下方图片可以懒加载，但快速跳到某节的用户仍然需要可识别占位。固定比例、简短替代信息和合理缓存可以降低等待感。图片加载完成后不要把阅读位置向下推，尤其长技术文章里一次布局移动会让读者失去代码上下文。观察滚动阅读过程，比仅拍首屏截图更容易发现问题。
外部图片不是没有维护成本
远程图片服务会变化、限流或下线。构建时获取并优化能固定发布结果，但增加构建网络依赖；运行时加载更简单，却把访问者的请求交给第三方。选择时应考虑来源许可、隐私与缓存策略。
不要为绕过图片服务限制而随意下载或重新托管资产，应先确认使用权限。对图像转换服务限制最大尺寸和允许来源，防止被用来生成大量昂贵变体。
验收时在多个视口检查实际下载宽度、正文可读性和布局稳定。用慢网络观察占位与 alt，确认图片失败时页面仍然可读。优化结论应来自真实资源与交互测量，而不是只报告某个图片格式比另一个“先进”。
若运行时允许 width、quality 和 URL 参数，攻击者可以生成大量不同组合。限定宽度集合、质量范围与允许来源，把未知组合拒绝或规范化。原图获取需要超时、最大字节和响应类型检查，重定向后的来源也要验证。仅检查 URL 扩展名不足以确认图片内容，也不能防止服务端请求内部资源。
构建时优化减少运行时依赖，但会增加发布耗时。远程资源不可用时选择构建失败还是使用已验证缓存，需要明确：承担证据的图片缺失可能应阻止发布，装饰图则可以采用合法缺省。不能自动替换成一张无关图库图，这会改变文章信息。保存资产来源和许可，方便以后更新或删除。
资源地址使用内容版本或哈希可以支持长缓存，新图片获得新地址。固定文件名覆盖则需要考虑浏览器和 CDN 旧副本。图像转换算法升级也可能改变输出，缓存键应包含有效转换版本，避免新规则读到旧文件。版本变化同时影响缓存与构建成本，应在部署报告中可观察。
为一张技术截图建立可复制的候选实验
选取一张包含正文小字、错误提示和一个关键按钮的合成截图，先明确读者任务：识别错误所在行并找到对应操作。生成有限尺寸候选，在真实文章容器中比较，而不是让每个文件都按原始尺寸打开。记录 CSS 显示宽度、设备像素密度、实际候选宽度、传输字节与文字可读性。实验值属于这张图与这组条件，不写成所有截图通用的压缩最佳值。
第一次比较只改变宽度，固定编码与质量；第二次固定宽度比较编码策略。同时改变多个参数，字节减少以后无法知道可读性损失来自哪里。对于文字，检查细笔画、标点和数字，错误码一个字符模糊就可能改变技术结论。照片可以接受的模糊边缘，不一定适用于终端与数据库执行计划截图。
浏览器缓存会影响候选选择，测试首次访问与回访分开。缩小视口后仍使用已缓存的大图，并不必然表示 sizes 错误；在独立首次条件下观察才能判断候选预算。高密度设备需要更多像素，但也有网络与内存约束，不能无限生成高倍尺寸。把任务可读作为质量底线，再在底线之上选择较小资源。
艺术方向需要保持论证内容一致
桌面完整截图显示错误发生前后，手机裁切只显示错误行。若文章结论依赖前一行配置，手机版本已经删除证据。准备艺术方向图时，列出不可省略信息与可裁掉背景，确保不同版本仍支持同一个论证。替代文本也要对应实际呈现，不能用完整截图描述裁切图中不存在的控件。
picture 可以选择不同资源，布局还需知道不同资源比例。若手机裁切更高，占位比例不能一直沿用桌面图，否则会在加载后移动正文。为各断点定义稳定容器，检查长标题、错误加载与放大按钮都不重叠。固定比例提供稳定起点，不代表必须把所有内容裁成一样的形状。
当小屏任务需要对比两张图，简单把它们缩进两列可能导致无法阅读。可以纵向排列，保留清晰标签，并在正文重复关键差异。若提供切换控件，读者需要能知道当前版本与变化位置，不用动画代替解释。图片优化应尊重比较任务，而不是只追求首屏同时放下更多缩略图。
放大体验有独立的资源与操作责任
读者点击查看原图时，可以按需下载更高分辨率资源，而非在首页预取全部原图。加载中保留当前小图与稳定控件，失败后允许关闭或重试，不把页面锁在空白弹层。原图可能非常大，仍需最大尺寸与字节预算。高分辨率不等于无限分辨率，任务只需识别界面细节时，经过验证的大图通常足够。
弹层需要键盘焦点、关闭动作与焦点返回；新标签查看则需要真实链接与明确名称。两种方式选择依据任务与维护成本。触摸缩放不能是唯一方式，键盘用户也应访问细节。图片加载后不抢走原本的焦点，关闭以后恢复文章位置。为一张可放大图新增交互，也意味着新增失败与可访问性验收。
资源地址不要携带长期访问凭据。内部界面截图在上传前脱敏，原图与缩略图都检查，不能只遮盖页面展示版本却让下载地址提供完整私人信息。图像编辑可能保留元数据，分享前检查必要信息与文件属性。技术博客的截图常含账户、路径与数据，内容安全是预算之外的另一硬约束。
生成管道如何防止变体失控
为每种用途定义批准宽度集合，例如列表、正文与放大各自有限候选，而不是允许每个组件自由请求任意宽度。实际数值根据布局确定，构建清单记录源图、转换版本与输出资源。新增一个展示用途时，先检查已有候选是否足够，再增加变体。无限自由会增加构建耗时、存储和缓存碎片，也让资产删除难以判断。
质量参数同样需要有限且有理由的策略。照片、截图与透明图可以采用不同预设，但作者应该知道如何选择。转换失败时，不自动退回可能过大的原始资源而不记录；承担证据的图片应明确阻断或使用已验证旧版本，装饰图可以有合法缺省。失败策略写清楚，才能避免一次图片服务故障让移动端突然下载全部原图。
升级转换算法后，比较代表性资产的尺寸、透明度、文字细节与色彩。输出哈希变化使新资源获得新缓存身份，但不证明质量更好。清理孤立变体之前，根据全站引用清单检查旧文章和已有页面版本仍是否需要。资产维护不能只围绕最新首页，因为长尾文章也属于公开内容。
让预算覆盖滚动与跳节，而不只是首屏
十五分钟长文可能包含多张执行计划与架构图。慢网络下连续滚动和直接锚点跳转，都会改变图片进入视口的顺序。观察懒加载是否及时启动、占位是否保留阅读位置以及多个图片请求是否挤占关键资源。首屏截图无法发现这些路径，需要完成真实阅读动作。
记录任务是否可完成、正文位置是否稳定与实际下载成本，保持三项分别可见。一个低字节结果如果读者看不清，就不是成功；一个清晰原图如果每次索引页都下载，也不是合理预算。通过具体任务、有限候选和失败体验形成持续检查，响应式图片才真正服务技术内容。
验收报告分开记录四种结果
传输结果记录下载字节和候选宽度；呈现结果记录关键文字是否清楚；稳定性结果记录加载前后位置变化；失败结果记录图片不可用时页面是否仍可理解。一个文件体积减少一半，不代表技术截图已经合格。一个页面没有布局移动，也可能因为占位过大造成阅读空洞，需要综合判断。
测试至少覆盖窄屏、宽屏和高密度条件，使用真实布局而非孤立图片组件。控制首次访问缓存，另外测试回访复用。慢网络观察首屏与跳节，关闭图片观察文字补充是否完整。把测量方法与样本明确写出，才可以比较调整前后效果；不要从一次桌面浏览得出所有移动用户都更快的结论。
参考：响应式图片、Astro 图片指南。