做前端优化的人基本都绕不开 CSS 图像拼合技术也就是俗称的 CSS Sprites、雪碧图。我第一次真正体会到它的价值是接手一个后台管理系统首屏五十六个小图标全部由独立img标签加载登录接口还没返回浏览器已经为了这些图标建立了几十次连接。后来我把这些图标按模块拼到三张大图里请求数从五十六掉到三个性能面板上的耗时肉眼可见在缩短。这篇文章不是把background-position文档抄一遍而是把我从手拼到自动化、再到踩坑复盘的全过程写下来包括定位坐标怎么算、高清屏要注意什么、现在还要不要继续用。如果你是刚接触 CSS 的进阶学习者或者正准备优化一个资源多、请求多的老项目这篇文章应该能帮你把雪碧图的来龙去脉理顺。哪怕你已经用过拼合我也建议重点看第 5 节那是我在真实项目里踩过的坑普通教程里很少会写。1. 一个小图标一个请求到底有多浪费1.1 请求开销往往比图片本身更贵很多人印象里图片加载的耗时主要由文件大小决定其实对 UI 图标这类小图来说真正花时间的是“建立连接”和“传递请求头”的过程。一个 16x16 的 PNG 可能只有 200~300 字节但一次 HTTP 请求需要经历域名解析、TCP 握手、发送请求头、等待服务器响应、接收内容。哪怕服务器的处理时间只有几毫秒网络往返时间RTT在现实环境里也可能达到几十甚至上百毫秒。我把这类开销比作外卖配送费你点一份 20 元的饭配送费可能只有 3 元但如果你把 20 份饭分开下单每次都要付一次配送费总成本立刻就不一样了。浏览器对同一域名下的并发连接数本来就有限制特别是在 HTTP/1.1 时代超出的请求会在队列里干等。于是页面上出现一种很典型的性能特征DevTools 的 Network 面板里一堆体积很小但耗时很长的请求横在时间线上页面首屏就这样被拖慢了。1.2 拼合技术的本质是“聚合请求”CSS 图像拼合技术的思路非常简单把多张小图合并成一张大图页面只需要加载一次再用 CSS 背景定位把需要的区域展示出来。这样网络层从 N 次往返变成 1 次图片数据从碎片变成连续大块。数据上合并后还经常带来一个附加收益体积变小。因为每个 PNG 文件都有自己的文件头和调色板信息合并成一张图后这些重复内容被消除压缩器还能利用整张图内的颜色分布做更高效的压缩。我经手的一个项目里图标从 56 个文件合并成 3 张雪碧图后图片总大小反而从 320KB 降到了 245KB。这里可以做一张表方便直观感受指标拼合前拼合后图标文件数563总请求数含其他资源8633图片总大小320KB245KB首屏网络耗时中位数1.8s1.1s1.3 缓存命中率是常常被忽略的优势还有一点很多人一开始没注意到拆开的 56 张小图意味着 56 个缓存项而合并后的 3 张图只有 3 个缓存项。页面每个入口都要在本地缓存里核对一次资源是否变化缓存项越多命中效率越低。尤其是复用程度高的后台系统所有页面共享同一份雪碧图时只需要一次下载之后切页面几乎全是本地命中这种体验在真实项目中非常明显。所以你看拼合技术虽然名字里有“图像”本质上解决的并不是图片解码问题而是网络传输问题。理解了这一点后面再谈定位和自动化逻辑就顺了。2. background-position 定位原理与坐标计算2.1 背景坐标系是反向的负值才是王道如果在普通 CSS 里设置background-position: 0 0背景图的左上角会贴着元素盒子的左上角显示此时背景图超出容器框的部分全部不可见。雪碧图的玩法就是利用这个特性让大图整体向左、向上移动把目标图标所在的那一小块区域挪进元素的可视区。假设目标图标在整张图中的左上角坐标是(x, y)那么对应的 CSS 就是background-position: -xpx -ypx;很多人第一次写雪碧图坐标时容易把方向搞反总想着“我要让图标往右移”结果填了正数图标反而往右边跑出去了。记住一点目标图标位于大图内部想让它的特定区域出现在容器里大图只能向负方向移动。x 轴向右y 轴向下所以偏移量是负的。2.2 千万别用百分比定位雪碧图background-position支持百分比但它的计算方式不是简单的“把背景图左上角放到容器的某个百分比位置”而是按公式(容器宽度 - 图像宽度) × 百分比来换算。当背景图很大、容器很小的时候同样的百分比会得到完全不同的像素值。即使在印象里应该居中的地方也没法和雪碧图的精确坐标对上。因此我的习惯是雪碧图里一律用像素单位或者用与background-size联动的calc表达式绝不用百分比。2.3 高清屏下的坐标换算一个公式解决现在很多项目都按 2 倍图导出图标也就是设计稿里 16x16 的图标实际切图是 32x32整张雪碧图也是 2 倍尺寸。页面通过background-size把大图缩放回显示尺寸。这时候坐标不能直接用原始切图的坐标必须除以缩放倍数。更严谨地写一下背景图原始像素宽度为W_src期望在页面里显示的宽度为W_disp缩放比例scale W_disp / W_src目标图标在原始图中的左上角坐标为(x_src, y_src)实际应填写的background-position是(-x_src * scale, -y_src * scale)举个例子原始图宽目标图标原始坐标background-sizescale应填写的 position800px(100, 200)400px auto0.5-50px -100px800px(100, 200)800px auto1-100px -200px这个换算无论手工拼还是用工具都要心里有数。如果你用 webpack-spritesmith 这类自动构建工具它生成 CSS 时一般会带上合适的background-size但如果你自己手写或者只导入图片就很容易漏掉这一步。我早期就在这上面栽过跟头后面第 5 节会展开讲。2.4 hover 切换状态拼合技术的高光用法拼合图除了省请求还顺带解决了一个体验问题hover 状态图标不会闪烁。把同一个图标的 normal 和 hover 状态纵向排在同一列CSS 里通过:hover切换background-position浏览器无需再加载新图片切换是瞬时的。比如.nav-icon { display: inline-block; width: 16px; height: 16px; background-image: url(sprite.png); background-repeat: no-repeat; background-position: -10px -10px; } .nav-icon:hover { background-position: -10px -34px; }这里的关键是两次定位的 x 坐标保持一致y 坐标改变所以拼图时最好把同一图标的不同状态按纵向排列。这种细节就是拼图规划时最常见的“看不见的经验”自动化工具一般不会替你考虑需要你提前约定。3. 手把手拼一张能直接上线的雪碧图3.1 先规划画布和间距别急着拖图很多新手拿到一批图标就直接打开 PS把图片挨个拖进去结果做到一半发现画布不够或者间距太挤只能重来。正确的第一步是先分类和计算。先把图标按用途分组一级导航一组、功能按钮一组、状态图标一组同一组内图标尺寸尽可能统一。如果有 hover/active 状态状态图要放在同一列方便后面写 CSS。间距上我习惯留 4px 或 8px 的透明间隔。如果导出的是 2 倍图间距也要跟着变成 8px 或 16px。间隔的作用有两个一是避免相邻图标的边缘像素在压缩后互相污染二是防高清屏缩放时出现半透明杂边。画布宽高的计算也不复杂例如 5 列、每列宽 32px、间隔 4px总宽就是32 * 5 4 * (5 1) 184px多一个 4px 是为了留出右侧边界。3.2 Photoshop 里的拼接步骤在 PS 里拼图核心就四步新建透明画布尺寸按上一步计算的结果设置。把每个图标图层拖入画布用“移动工具”并开启参考线确保图标对齐到相同网格。打开“信息面板”记录每个图标左上角相对于整张画布的坐标。确认无误后CtrlShiftS 导出 PNG。我建议导出前把所有参考线隐藏避免参考线被当成内容输出。坐标记录这一步最容易出错毕竟是几十个数字手抄。如果你不想手工抄可以给图层统一按icon-home这样的名称命名然后写一个 PS 脚本批量读出位置生成 CSS但这个门槛略高。对新手来说先用小批量的图练一遍手后面再过渡到自动化。3.3 在线工具和桌面工具怎么选不想在 PS 里手动拼也可以借助工具。下面是我用过、也见过别人常用的几类工具类型优点注意点TexturePacker桌面软件功能强、自动排版、可导出多端格式付费免费版有功能限制Sprite Generator在线网站在线工具操作简单上传即可生成有素材隐私风险别传敏感图片Figma / Zeplin 插件设计协作和设计稿联动适合团队需要设计阶段就规划好PhotoShop 手动拼设计软件可控性最强容易漏坐标、效率低这里专门提醒一句很多在线拼图网站会把上传的图片保存在自己的服务器上做处理如果你用的是公司内部素材一定要谨慎最好用本地工具或自建脚本。这不是技术问题是合规风险。3.4 导出格式与压缩导出的格式直接影响雪碧图体积。我的经验是纯色、扁平、边缘没有抗锯齿需要的图标优先导出 PNG-8体积最小。带半透明、柔边、多色彩渐变的内容用 PNG-24 或 PNG-32。如果目标用户浏览器较新也可以输出 WebP 雪碧图并配合 fallback但复杂度会高一些。不要把 JPEG 当作雪碧图主要格式因为它不支持透明而且压缩后边缘会出现明显噪点。导出后还可以用 TinyPNG 这类工具再压一轮。但我踩过一个小坑压缩工具在优化时有可能裁掉图片透明边缘或改变图像尺寸导致原来的坐标全部失效。所以压缩一定要放在坐标导出之前坐标必须以最终压缩后的图片为准。3.5 用一段完整代码验证拼合结果拼完之后怎么确认坐标没错写一个最简单的页面把所有图标类都摆出来看比肉眼在 PS 里盯像素要靠谱得多!DOCTYPE html html langzh-CN head meta charsetUTF-8 style .icon { display: inline-block; width: 32px; height: 32px; background-image: url(sprites.png); background-repeat: no-repeat; } .icon-home { background-position: -12px -16px; } .icon-user { background-position: -52px -16px; } .icon-setting { background-position: -12px -56px; } /style /head body span classicon icon-home/span span classicon icon-user/span span classicon icon-setting/span /body /html如果某个图标显示出来位置不对多半是坐标抄错了如果多个图标都偏移同样的距离还要检查容器尺寸或background-size是否和设计稿一致。这类快速验证页面留着也方便后续回归。4. 让构建工具替你完成拼合自动化链路4.1 手工维护的痛点在哪手工拼图在小项目、一次性活动页里没问题但只要项目进入长期迭代痛点就非常明显。增加一个图标意味着重新拼接、重新记录坐标、手工修改 CSS。如果某个图标删了还得小心别让其他坐标失效。在这种重复劳动下人的注意力很容易出错而且团队协作时每个人可能都有自己的拼图习惯最后的产出难以维护。所以我的建议很直接如果是持续迭代、多人协作的前端项目尽早把拼图交给自动化工具这比任何规范文档都更有约束力。4.2 Webpack 下的自动化配置在 Webpack 项目里我常用webpack-spritesmith。它做的事情是扫描指定目录下的所有 PNG自动排版生成一张雪碧图同时生成一份对应的 CSS 文件。配置大概是这样的const path require(path); const SpritesmithPlugin require(webpack-spritesmith); module.exports { plugins: [ new SpritesmithPlugin({ src: { cwd: path.resolve(__dirname, src/assets/icons), glob: *.png }, target: { image: path.resolve(__dirname, src/assets/sprite.png), css: path.resolve(__dirname, src/assets/sprite.css) }, apiOptions: { cssImageRef: sprite.png }, spritesmithOptions: { padding: 4 } }) ] };注意几个关键配置cwd是图标素材目录target.image是生成的雪碧图路径target.css是生成的样式文件路径padding就是我前面说的间隔。这个插件基于 spritesmith 库默认只处理 PNG如果你的素材是 JPG 或 WebP就需要换别的方式或者先转成 PNG。4.3 生成的 CSS 怎么接进业务代码插件生成的 CSS 大致长这样.icon { background-image: url(sprite.png); background-repeat: no-repeat; } .icon-home { width: 32px; height: 32px; background-position: -12px -16px; } .icon-user { width: 32px; height: 32px; background-position: -52px -16px; }使用时在 HTML 里加一个类名即可样式会自动匹配。如果你在 React/Vue 组件里用也可以让插件额外输出一份 JSON 映射动态生成图标样式。这类生成式 CSS 的好处是坐标永远不会手写错因为插件是根据实际排版自动计算出来的。还有一点值得提自动化生成的 CSS 通常会包含width和height这和手写时的习惯不太一样。好处是减少类名搭配时尺寸不匹配的问题坏处是如果图标有固定的 CSS 尺寸覆盖需求你可能还要小心和权重做斗争。所以项目里最好约定雪碧图类只负责背景定位元素本身的尺寸用工具类去控制不要混在一起改。4.4 自动化也要分场景不是所有项目都适合虽然自动化很香但我也见过把本来很轻量的静态页面搞得很重的例子。如果这个项目只有两个静态页、图标加起来不超过十个用 postcss-sprites 或者手工拼一次反而更简单。自动化适合的是那些图标数量多、会频繁增删、并且团队多人协作的中大型项目。另外如果不想引入 Webpack 插件也可以写一个非常简单的 Node 脚本调用 spritesmith 原生库完成拼图和 CSS 输出。这样虽然前期要写一点代码但完全不依赖框架在非 Webpack 项目里也能用。这个思路特别适合那种没有完整工程化的老项目需要你稍微平衡一下成本。5. 那些真正让我吃过亏的细节坑5.1 background-size 缩放在高清屏上的坐标错位这是我第一次引入 2 倍雪碧图时踩过的坑。图标切图是 2 倍尺寸我按照原始坐标直接写了background-position: -200px -160px结果图标在页面上偏移得完全不对。排查了半天才发现容器设置的是background-size: 400px auto也就是说大图被缩放到原来的一半那么原始坐标也必须跟着乘以 0.5。正确写法是-100px -80px。后来我把这个换算逻辑抽成了一个 Sass 函数传入原始坐标和缩放比自动生成background-position。如果你不用 Sass建议至少写成 CSS 变量:root { --sprite-scale: 0.5; } .icon-home { background-position: calc(-200px * var(--sprite-scale)) calc(-160px * var(--sprite-scale)); }这种用法在生产环境没什么问题但会让 CSS 的可读性降低所以我更推荐用构建工具自动生成或者把换算逻辑放在 JS 里做。5.2 一个图标改动导致整张雪碧图缓存失效拼合带来性能收益的同时也引入一个运营层面的痛点某个图标改了如果文件名不变浏览器会用旧缓存用户看不到变化如果加上版本号哪怕只改一个小图标整张雪碧图也会重新下载。对于活动页、专题页这类更新频繁的场景这个开销可能比一次加载 50 个独立小图还要大。我的处理思路是拆分把变化频繁的内容图标比如运营位图标单独拼一张小的雪碧图把几乎不变的框架图标比如系统导航、通用操作按钮拼成另一张。这样即使内容图标经常更新框架图仍能长期命中缓存。另一个办法是设定缓存策略给大图设置一个合理的max-age同时在更新时使用内容 hash 改名而不是简单加查询字符串。实际选哪种取决于你项目里图标的更新频率。5.3 background 简写把整张图干掉的坑另一个让我相当无语的坑是background简写。项目里有人为了让元素背景变白写了.icon { background: #fff; }结果这个图标直接消失。原因很好解释background简写会重置所有背景子属性包括background-image和background-position。图标还在但背景图被简写覆盖掉了。遇到这种情况我的建议是使用雪碧图的元素背景相关样式一律只写长写属性也就是background-image、background-position、background-repeat、background-size分开写不要顺手用background简写去覆盖。如果必须和别的背景叠加就把雪碧图类单独放在一个 class 上不要和背景色写在同一个选择器里这样误伤概率会小很多。5.4 相邻图标边缘串色间距与容器尺寸的较量有时候坐标明明算对了显示出来的图标边缘却带着隔壁图标的残影。原因大概率出现在两个地方一是拼图时间距留得太小压缩后的抗锯齿像素渗透到了相邻区域二是容器尺寸和图标显示尺寸不一致比如图标显示 32px但雪碧图里图标和左边界的距离只有 30px于是旁边图标的边缘漏了进来。解决比较简单拼图时留足 4px 以上透明间隔2 倍图按比例留 8px 以上容器宽高和图标 CSS 尺寸保持一致。如果你用 PS 拼还可以在每个图标周围单独加 1~2px 的透明 padding进一步降低边缘噪声。这类细节在自动拼图工具的默认参数下通常没问题但手拼时一定要养成习惯。5.5 调试定位错位的最快方法最后分享一个排查定位问题的调试套路。图标显示不对时先给元素加一个临时边框或高亮背景确认容器本身尺寸无误然后在 DevTools 里手动改background-position的值观察它朝哪个方向偏移。如果想快速判断整张大图在页面上的布局可以临时把background-size设得很大并让background-position回到0 0这样等于把整张大图平铺出来你能直接看到目标图标在雪碧图中的真实位置比对着坐标表猜要直观得多。排查完记得把临时样式删掉避免带着调试样式上线。6. 现在的技术环境里雪碧图还要不要用6.1 HTTP/2 之下“减少请求”还重要吗这是很多人争论的焦点。HTTP/2 带来了多路复用多个请求可以在同一条 TCP 连接上并行传输看起来那些排队问题都被解决了。但也要看到另一面每个请求仍然有独立的请求头和额外的调度开销服务端也需要处理更多并发流。如果你的页面里只是零星几张图当然不需要拼合但如果是几十个 UI 图标合并成一张雪碧图仍然能减少无谓的头部开销也能让 CDN 命中率更集中。很多老项目实际上仍然是 HTTP/1.1 的环境或者 CDN 回源链路并没有完全支持 HTTP/2。在这些场景下雪碧图依旧是一个稳定、兼容性极好的优化方案。我建议做技术选型前先看真实的部署环境而不是只看本地 Chrome 的网络面板。6.2 SVG Symbol Sprite矢量图标的新思路如果图标本身都是矢量图形我更推荐 SVG Symbol Sprite。它的做法是把所有 SVG 图标作为symbol放在同一个 SVG 文件里页面通过use引用一次加载任意缩放不模糊还能用currentColor控制颜色适合做主题换肤。它和位图雪碧图的区别本质上是把“拼图”换成了“拼矢量”思想其实一脉相承。简单示例svg xmlnshttp://www.w3.org/2000/svg styledisplay:none symbol idicon-home viewBox0 0 24 24 path dM3 10.5 12 3l9 7.5V21h-6v-6H9v6H3z/ /symbol /svg svg classicon aria-hiddentrue use href#icon-home/use /svg要注意的是use的兼容性和跨域引用在老旧浏览器里有不少边界情况如果项目要兼容 IE11还是得做 fallback。SVG 图标适合那些颜色、尺寸都比较规整的 UI 图标但不太适合照片级或多色复杂图形。6.3 字体图标、Base64 和纯 CSS 的边界字体图标Icon Font在早年很流行但现在使用得越来越少主要原因是多字体文件加载、渲染抗锯齿不稳定以及无障碍和可访问性方面的麻烦。Base64 内联图片适合极少量、体积很小的图片可以直接嵌进 CSS 里减少一个请求但体积通常比原始文件膨胀 33% 左右而且同一张 Base64 图如果出现在多个页面其实是多次复制。纯 CSS 图形渐变、遮罩、裁切能模拟一些简单图标但复杂场合效率太低。所以这些方案都有明确的边界谈不上谁替代谁。6.4 我的选型建议以我现在的习惯会按下面这张表来选择场景推荐方案老项目、HTTP/1.1 环境、大量位图图标CSS 雪碧图新项目、矢量图标、需要换肤SVG Symbol Sprite极少量小图、不想额外发请求Base64 内联图标更新频繁、运营位素材独立小图 合理缓存有大量图片内容、不是图标交给懒加载与响应式图片选型的关键其实不是“用不用雪碧图”而是看你的资源特征是否只有少量图标是否要频繁更新浏览器环境是否支持多路复用把这些因素摆在台面上答案往往很清晰。写到最后分享一个我个人保持了很久的习惯任何拼图方案无论是手工还是自动化我都会把原始切图文件、拼接参数、坐标规则和导出格式写进项目文档。很多项目三个月后回看已经没人记得当时的背景图为什么是 184px 宽、间距为什么留 4px文档能省掉一大半维护成本。我最开始也是随手拼、随手写吃过亏之后才明白这类“看不见的约定”才是一个优化方案能不能长期维持的关键。