问你一个特别有画面感的场景：你打开一个后台管理页面，页面顶部刷出十几个小图标，有的先弹出来，有的卡了半秒才出现，整个页面像没穿好衣服一样。你可能会甩锅给网速，但干前端的老鸟都知道，问题多半出在请求数量上——每一个小图标都是一次独立的HTTP请求。
CSS雪碧图（也叫CSS Sprites，中文社区习惯叫它雪碧图，因为Sprite这个词既能翻译成精灵，又恰好是雪碧的英文名）就是专门治这个病的。它把所有小图标合并到一张大图上，页面只请求一次，然后用background-position去精确“裁剪”出需要的那一块。听起来玄乎，其实原理特别简单，把坐标搞明白就能直接用。
这篇文章我会从最核心的请求原理讲起，然后完整跑通一套“切图、合并、读坐标、写CSS、适配多倍屏”的流程，源码可以直接抄走改改就用。另外还会把踩过的坑、排查方法和面试常考点一起整理出来。适合三种人看：刚学CSS不久、还在一个个切图的前端新人；准备前端面试、想把这个点讲出深度的人；以及项目里图标特别多、想找个稳定维护方案的同学。
1. 为什么雪碧图能救命：先算清HTTP请求和图片加载的时间账
1.1 一个例子看清“小图片排队”有多慢
咱们先做一个极端假设：你的页面顶部有20个小图标，每个图标单独保存成一张20KB的PNG。按普通思路，CSS里写了一条规则引一张图，浏览器就得发一次HTTP请求。20张图就是20次请求，哪怕你服务器延迟只有20毫秒，光建立连接、等待响应、传输数据，20个图标全部到位往往需要几百毫秒甚至更久。
更麻烦的是浏览器对同一域名的并发连接数有限制。HTTP/1.1协议下，同一个域名同时只能开6个左右的TCP连接，超出部分只能排队等。也就是说，第6张之后的图标必须等前面的下载完才能开始下载，就像超市结账只开了一个窗口，后面的人再着急也得站着等。这就是为什么有些页面其他内容都加载出来了，图标区还是一片空白。
这个“排队”现象在某些弱网环境的移动端尤其明显。我早年接过一个老旧的ERP系统改造，页面侧边栏有几十个浮层菜单图标，每个都是独立小图。用户从WiFi切到4G甚至3G时，整个侧边栏要转好几秒圈。性能排查工具一打开，光图片请求就有四十多条，占了总请求数的70%以上。当时第一个优化动作就是把这些菜单图标合并成三张雪碧图，首屏体感速度快了不止一档。
1.2 合并后省下的不只是请求次数，还有“图片本身的体积”
雪碧图的核心思路，是把许多小图拼成一张大图。听起来只是“把多个文件变成一个大文件”，但它省下来的东西有两层：
第一层是请求次数。20次HTTP请求变成1次，并发排队问题基本消除。就算HTTP/2普及后连接可以复用，单张图片依然能少掉很多请求头、响应头、TLS握手带来的额外开销。第二层是总字节数。每张PNG或JPG文件本身都带有元数据、颜色配置、压缩头等信息，独立存储时这些信息要复制好几份；合并成一张大图后，这些公共信息只保留一份，整体体积通常会小于所有小图相加。
也就是说，雪碧图并不是“把20张小图物理合并成一张更大的图”这么简单，它同时优化了网络传输层的请求路径，以及图片文件的冗余存储结构。理解到这一层，你就知道它为什么能在老一代前端性能优化里占据核心位置。
1.3 先认识三条路线：雪碧图、iconfont、SVG Sprite
在动手之前，先把思路理清楚。如今做图标方案，不像十年前只有CSS雪碧图这一条路可走。目前主流做法大致有三种：
CSS雪碧图：把位图PNG合并成一张大图，靠background-position定位。适合图片颜色丰富、形状复杂的图标，兼容性最好，从IE6到现代浏览器都能用，缺点是后期维护坐标麻烦。
iconfont（字体图标）：把图标做成字体文件，用CSS的font-family引用，再用伪元素的content写入对应编码。优势是矢量无限放大不糊，改色方便，改一个color就全变了；缺点是一个图标只能单色，想做渐变或多色会非常吃力。
SVG Sprite：把多个SVG图标放进一个<svg>文档里，用<symbol id="...">定义，然后在页面里用<use href="#id">引用。这是现代项目里我最推荐的方向，支持多色、支持CSS控制大小颜色、可维护性比位图雪碧图高很多。
但别因为有了新方案就觉得雪碧图过时了。老项目改造成本、某些特殊图形效果（比如复杂的位图纹理图标）、以及部分低版本浏览器的兼容要求，都让CSS雪碧图依然有它的生存空间。所以我的态度是：三条路线都要会选，而CSS雪碧图作为最底层的“看图拼图定位”能力，是理解其他方案的好基础。
2. 雪碧图原理拆解：background-position定位其实只需要一个负值公式
2.1 坐标系本质：background-position到底在移动谁
很多新手第一次写雪碧图，看到background-position: -36px 0;这种负值就懵了：为什么是负数？背景图不是应该往右挪吗？这里的关键在于——background-position设置的是“背景图相对于容器原点”的位置，而不是“容器相对于背景图”的位置。
我习惯用一个投影仪胶片的类比。容器就是你眼前的幕布，背景图是一辆可以移动的胶片车。幕布不动，你想看胶片上靠右边的画面，就得把胶片车往左边拖，拖得越多，幕布显示出的画面就越靠右。整个过程中的移动方向恰好与画面方向相反，这就是负值的来源。
正式点说：background-position: X Y;中X表示背景图左边缘与容器左边缘的水平距离，Y表示背景图顶边缘与容器顶边缘的垂直距离。当背景图比容器大时，我们想要显示中间的某一小块，就必须让背景图“左上角”跑到容器左上角的上方和左方去，所以呢X、Y基本都是负数。
再拆一个最常用的公式。假设每个图标在大图中占据的格子宽度是cellW、高度是cellH，目标图标排列在第col列（从0开始）和第row行（从0开始），那么它的背景定位就是：
background-position: -col * cellW -row * cellH;注意这里的cellW和cellH不是图标本身尺寸，而是包含间距的“单元格尺寸”，后面实战部分我会用具体数值走一遍。
2.2 三种方法快速拿到图标坐标
理论公式聊完，实践里第一步往往是“这张大图里的图标，坐标到底是多少”。新手最常见的傻办法是用截图工具一个一个量，效率极低。我有三种办法推荐：
第一种，用Photoshop。打开拼接好的雪碧图，按Ctrl+R调出标尺，再拖出参考线对齐图标边缘，属性面板里就能看到参考线的精确坐标。这个办法老派但很通用，适合手头只有PS的设计师或前端。
第二种，用Figma。选中大图里的某个图标切片，右侧属性面板会直接显示它的X、Y坐标和宽高，复制出来就能填进CSS。Figma这种“所见即所得”的方式最省脑力，推荐给新同学。
第三种，完全不打开设计工具。在浏览器开发者工具里给元素临时加一个很大的background-position，然后逐步调整数值，肉眼对齐到目标图标。虽然简陋，但应急时非常快。
如果你是前端老手，可能会进一步用构建工具自动生成坐标，这属于进阶玩法，我放在后面第四节“维护可自动化”的部分详细讲。
2.3 一个最小可运行示例：先跑起来再说
原理和公式说完，来一个最短的能跑通的例子。假设我有一张雪碧图sprite.png，里面水平排列了两张32x32的图标，第一个图标在(0,0)，第二个图标在(36,0)（中间留了4像素间距）。
HTML里只需要一个普通的div：
<div class="icon icon-cart"></div>CSS里这样写：
.icon { width: 32px; height: 32px; background: url("sprite.png") no-repeat; } .icon-cart { background-position: -36px 0; }第一行图标显示的是大图左上角第一块区域，也就是(0,0)；第二行图标把背景图向左移动36像素，容器显示的是从(36,0)开始的32x32区域，正好是第二个图标。这里有个细节新手常忽略：容器宽高必须和图标设计尺寸一致，否则很容易把旁边的内容也框进来。
跑完这个例子，你对雪碧图的基本流程就有了体感。接下来我们进入真实项目级别的实战，把从切图到上线的环节全部走一遍。
3. 实战源码来了：手把手做一套导航图标雪碧图
3.1 准备工作：切图规范和命名规则
做雪碧图前先定规则，否则图一多就会乱。我一般按照这套规范走：
图标统一放在一个目录，比如src/assets/icons/；文件名用“功能名”命名，如icon-home.png、icon-cart.png、icon-order.png、icon-user.png；必须保证每个图标的视觉尺寸一致，如果设计稿里图标大小不统一，先统一缩放到同一尺寸，再做合并，不然后面写容器宽高会痛不欲生。
合并时“单元格”和“间距”是另外两个关键概念。单元格指的是每个图标占据的矩形区域，它比图标本身大，因为要在四周留出透明边距。我建议间距至少4像素，条件允许的话用8像素。这个透明边距有两个作用：一是防止相邻图标被意外截到；二是保留一定的呼吸空间，避免图标边缘出现锯齿或杂色。
如果你用工具自动拼接，绝大多数雪碧图生成器都会提供padding参数，直接填4或8。如果是手动拼图，记得把画布按“图标尺寸+间距”的倍数来建，这个后面读取坐标时会容易很多。
3.2 用Figma/PS读取坐标并导出
拿Figma举例，四张32x32图标横向排列，每张之间留4像素间距，左边距和上边距暂按0处理。那么合并后的画布尺寸就是：宽 = 4个图标 + 3个间距 = 4*32 + 3*4 = 140像素，高 = 32像素。
选中第一个图标，Figma右侧显示X=0，Y=0；第二个图标X=36，Y=0；第三个X=72，Y=0；第四个X=108，Y=0。把这些数字记下来，就是你写CSS时需要的原始坐标。
如果是PS，操作路径是：文件->脚本->将图层导出为PNG，插入参考线后用“信息”面板读取坐标。PS和Figma导出的PNG都保持透明背景即可，注意不要带白色背景层，否则合成后看不到透明边界，坐标判断容易出错。
导出完成后再对图片做一次压缩。PNG可以用TinyPNG这类在线工具，或者本地用pngquant命令行工具。压缩不影响坐标，但能明显减小雪碧图体积。别小看这一步，有次我把一张600KB的雪碧图压到180KB，加载速度立刻舒服多了。
3.3 导航栏完整源码：HTML结构 + CSS定位 + hover状态
现在开始写真正能用的代码。场景是一个常见的底部导航栏，四个图标：首页、购物车、订单、我的。我同时准备了两套颜色状态，第一行是默认色，第二行是高亮色，高亮图标放在Y=40的位置（32高度+8垂直间距后，第二行起始Y就是40）。
我先给出雪碧图的排版参数，方便你对照阅读：
| 图标名 | 列坐标 | 行坐标 | CSS background-position（默认） | CSS background-position（hover） |
|---|---|---|---|---|
| icon-home | 0 | 0 | 0 0 | 0 -40px |
| icon-cart | 1 | 0 | -36px 0 | -36px -40px |
| icon-order | 2 | 0 | -72px 0 | -72px -40px |
| icon-user | 3 | 0 | -108px 0 | -108px -40px |
HTML结构如下：
<nav class="nav"> <a class="nav-item" href="#"> <span class="nav-icon nav-home"></span> <span>首页</span> </a> <a class="nav-item" href="#"> <span class="nav-icon nav-cart"></span> <span>购物车</span> </a> <a class="nav-item" href="#"> <span class="nav-icon nav-order"></span> <span>订单</span> </a> <a class="nav-item" href="#"> <span class="nav-icon nav-user"></span> <span>我的</span> </a> </nav>CSS部分：
.nav { display: flex; justify-content: space-around; align-items: center; height: 56px; background: #fff; border-top: 1px solid #eee; } .nav-item { display: flex; flex-direction: column; align-items: center; gap: 2px; text-decoration: none; color: #666; font-size: 12px; transition: color 0.2s; } .nav-icon { width: 32px; height: 32px; background: url("sprite.png") no-repeat; /* 背景图原始尺寸 140px x 80px，后面多倍屏适配再细说 */ } .nav-home { background-position: 0 0; } .nav-cart { background-position: -36px 0; } .nav-order { background-position: -72px 0; } .nav-user { background-position: -108px 0; } /* 鼠标移入时，切换成第二行高亮图标 */ .nav-item:hover .nav-home { background-position: 0 -40px; } .nav-item:hover .nav-cart { background-position: -36px -40px; } .nav-item:hover .nav-order { background-position: -72px -40px; } .nav-item:hover .nav-user { background-position: -108px -40px; }这里多说一句关于:hover与伪类选择器的关系。你可能在面试题里见过“CSS伪类选择器怎么用”这种问题，上面这段代码就是最典型的实战场景：用:hover切换雪碧图的坐标，相当于用状态选择器驱动背景偏移。理解了这一点，比单纯背选择器语法有用得多。
用这种方案，页面只请求了一次sprite.png，四个图标加上两套颜色状态全都在里面了。而且切换hover时不会闪白，因为图片早就加载完了，只是背景位置变了。
3.4 换上2x图：Retina高清屏适配的正确姿势
如果现在把sprite.png直接放到iPhone或高分辨率屏幕上，图标大概率会发虚。原因是设备像素比（DPR）是2或3，一张32x32的逻辑图标需要64x64甚至96x96物理像素，而我们只给了32x32的图。
正确做法是：准备一张2倍尺寸的雪碧图。也就是物理尺寸从140x80变成280x160，图标和间距全部放大一倍，然后通过background-size把它“按设计稿逻辑尺寸”缩放回去。
.nav-icon { width: 32px; height: 32px; background: url("sprite@2x.png") no-repeat; background-size: 140px 80px; /* 关键：把280x160的图缩放成140x80来用 */ } .nav-home { background-position: 0 0; } .nav-cart { background-position: -36px 0; } .nav-order { background-position: -72px 0; } .nav-user { background-position: -108px 0; }注意一个极易踩坑的细节：加了background-size之后，background-position仍然按“缩放后的逻辑像素”来算，所以-36px 0这种坐标不需要除以2。因为背景图整个被缩小了，36逻辑像素在物理图上对应的就是72物理像素，正好落在2x图的正确位置上。
当然，如果你的项目需要兼容低版本安卓或某些国产浏览器，建议用媒体查询区分DPR，而不是直接写死一张2x图：
@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi) { .nav-icon { background-image: url("sprite@2x.png"); background-size: 140px 80px; } }这样做的好处是普通屏仍然加载1x图，节省流量；高清屏自动切到2x图，保证清晰。不过现代前端项目用Webpack处理图片时，通常会用image-set或者构建插件自动完成这件事，手写媒体查询属于备选方案。
3.5 进阶玩法：用同一张雪碧图做CSS帧动画
雪碧图不只是放图标，它还可以做帧动画，而且玩法很有意思。原理是：把动画的每一帧水平排列在一张大图上，然后用background-position随时间逐帧切换，看起来就是连续播放的小动画，类似翻页动画书。
我举个常见的例子：一个加载中的小圆环，共8帧，每帧64x64，横向排列，图片总宽度512像素。容器固定64x64，每隔一段动画时间切换一次背景坐标。
.loading { width: 64px; height: 64px; background: url("loading-sprite.png") no-repeat 0 0; animation: spin-frames 0.8s infinite; } @keyframes spin-frames { 0% { background-position: 0 0; } 12.5% { background-position: -64px 0; } 25% { background-position: -128px 0; } 37.5% { background-position: -192px 0; } 50% { background-position: -256px 0; } 62.5% { background-position: -320px 0; } 75% { background-position: -384px 0; } 87.5% { background-position: -448px 0; } 100% { background-position: -512px 0; } }有人可能会问：为什么不用steps(8)这种一步到位的写法？这里有个小坑：steps()的分段方式在不同浏览器里存在边界差异，尤其最后一步容易跳到空白区域。手动写百分比虽然多几行代码，但每个动画帧都能精确控制，对新手来说更不容易出错，排查问题也更直观。
这个技巧在实际项目里特别适合做Loading动画、开关切换、人物跑动、数字滚动等效果，一张图就能撑起一个完整的动效，比引入几十张零散帧图要稳定得多。
4. 常见问题与排查技巧：多倍图、白边、维护成本一次说清
4.1 图标错位、有白边、变模糊，问题根源在哪里
先说图标错位。九成情况是坐标算错。排查方法很简单：先确认每个单元格尺寸cellW和cellH是否计算正确，再看看目标图标是不是最后一行或最后一列。很多自动生成的雪碧图，最后一格右侧和下方并没有预留间距，这时候按“所有格子都带间距”的公式去算坐标，最后一个图标就会偏。
再说白边。如果你看到图标边缘有一圈淡淡的杂色或半透明边，多半是合并图片时没留够间距，或者导出时使用了抗锯齿边缘。解决办法是合并时给每张图标四周多加几个像素的透明padding，导出时使用“透明背景”而不是白色背景。
最后说模糊。图标在普通屏清晰、高清屏模糊，基本可以断定没用多倍图。前面3.4节已经从DPR角度讲过了，这里补充一个排查技巧：在开发者工具里把DPR模拟成2或3再刷新页面，观察图标是否会变模糊，这个方法能快速定位问题到底出在图片资源还是CSS适配。
4.2 维护太痛苦？用构建工具自动生成雪碧图和坐标
如果你维护的项目图标特别多，每换一个图标都要手动重新拼图、重新量坐标，确实会让人崩溃。这时候可以考虑把雪碧图生成自动化。
前端社区有不少方案，比如Webpack的spritesmith插件和postcss-sprites。思路是一致的：把零散图标放进指定目录，构建时自动合并成一张或几张雪碧图，同时自动生成一份包含精确坐标的CSS/Sass/Less文件，页面里直接引用生成的混合类即可。
一个简单的Spritesmith调用示例如下（Node脚本方式）：
const path = require("path"); const Spritesmith = require("spritesmith"); Spritesmith.run({ src: ["./icons/*.png"], padding: 4, algorithm: "top-down", }, (err, result) => { if (err) throw err; console.log(result.image); // 图片Buffer，保存为文件 console.log(result.coordinates); // 每个图标的坐标对象 console.log(result.properties); // 整张图片的宽高 });跑完这个脚本，你会得到一个大型Buffer图片和每个图标精确的坐标对象，然后交给自定义函数去生成CSS类。这种方式对大项目来说是最省力的，改一个图标就重新构建一次，坐标永远能对齐。
不过自动生成也不是万能的。图标命名混乱、尺寸不统一、目录结构不合理，都会让构建产物变得不可控。所以在引入自动化工具之前，先把素材规范定下来，这样才能真正享受自动化的便利。
4.3 对比其他icon方案：什么时候该用雪碧图
选择方案时，我会先问三件事：图标数量多不多？颜色单不单色？兼容性要求高不高？
| 对比维度 | CSS雪碧图 | iconfont | SVG Sprite |
|---|---|---|---|
| 请求数量 | 合并后1张 | 1个字体文件 | 1个SVG文件或内联 |
| 多色/渐变 | 支持 | 不支持，单色 | 支持 |
| 高清屏适配 | 需要多倍图 | 矢量，天然清晰 | 矢量，天然清晰 |
| 维护成本 | 坐标手动或自动生成 | 换图标要重新生成字体 | symbol组织较清晰 |
| 浏览器兼容 | 最好 | 较好（IE6+） | 现代浏览器为主 |
| 典型场景 | 老项目、位图图标 | 简单单色图标 | 现代项目、多色图标 |
从这张表能看出，CSS雪碧图的“不可替代性”在逐渐减弱，但在兼容性要求严苛、图标精致复杂、无法接受字体版权或SVG渲染差异的场合，它依然是稳妥的选择。前端开发在实际工作中很少做“非此即彼”的选择题，更多时候是让各种方案并存在项目里。
4.4 问题速查表
最后把常见问题整理成一张速查表，方便你遇到问题时直接对照。这些坑基本都是我实际踩过的，每一条背后都有一段“调了半天最后发现是这么回事”的经历。
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 图标显示成旁边另一个图标的一部分 | 坐标偏移少了/多了单元格尺寸 | 用设计工具重新量坐标，核对cellW/cellH |
| 图标边缘有杂色或半透明白边 | 合并时没留间距 | 重新生成雪碧图，图标之间加4px以上padding |
| 高清屏模糊 | 用了1x图，没做多倍屏适配 | 用2x图并添加background-size |
| 加了background-size后定位错乱 | 坐标没有按逻辑尺寸计算 | 确认background-position按缩放后的逻辑像素写 |
| 背景图出现平铺重复 | 忘记写no-repeat | 改成background: url(...) no-repeat; |
| 雪碧图加载太慢白屏 | 单张图片过大 | 压缩PNG、拆分雪碧图、考虑WebP格式 |
| 改一张图要重新拼整张 | 没有自动化 | 引入spritesmith/postcss-sprites等工具 |
| hover切换图标时闪烁 | 图片没预加载，鼠标移上时才下载 | 合并后只有一张图，天然避免；仍闪就检查缓存策略 |
5. 面试加分项：前端面试问雪碧图时怎么回答才显深度
5.1 一句话讲清原理，让对方觉得你不只是在背八股
面试官问“说一下雪碧图的原理”时，很多同学会回答：“就是把多张小图合并成一张大图，然后用background-position定位。”这个答案对，但不加分，因为它只是复述了定义。
我建议在定义之后立刻补一句关键解释：“background-position做到的本质是，让一张超出容器尺寸的背景图移动到我们希望显示的坐标区域，负值是因为移动方向和目标区域的方向相反。”这句话一出来，面试官就知道你不是背的，而是真懂坐标系。
紧接着可以用一个很小的例子辅助说明：比如两个32x32图标横向排列，第二个图标的定位是background-position: -36px 0，因为它的左边缘X坐标是36。简洁、具体、有画面感，面试官想打断你都难。
5.2 从HTTP层面展开：为什么减少请求一定有用
如果面试官继续追问“为什么雪碧图能优化性能”，别只答“减少请求数”，要从四个层面展开：
第一，减少HTTP连接数。HTTP/1.1时代同域名并发连接数有限，减少请求能直减少排队等待时间。第二，减少TLS握手和请求头开销，尤其HTTPS场景下，每一次新请求几乎都要重复握手，合并成一张图后只做一次。第三，减少图片元数据体积。多张小图的文件头、颜色配置等信息合并成一份，总字节数明显下降。第四，减少页面图标区域的白屏时间，因为所有图标同一次请求到达，视觉上会更“齐整”。
如果面试官提到HTTP/2，也不要慌。可以承认HTTP/2多路复用让并发连接压力缓解了，但请求头开销、图片元数据冗余等问题依然存在，所以雪碧图在部分场景下仍有优化价值。重点在于展示你对“为什么优化”“优化了什么”的思考过程，而不是死记一个结论。
5.3 横向对比不掉坑：雪碧图、iconfont、SVG Sprite怎么选
面试里很喜欢考对比题。回答时切忌一刀切说“哪个更好”，而是给一个选型框架。
我会这样说：如果项目需要兼容老浏览器，特别是IE6到IE8一段，图标又是位图风格，CSS雪碧图是最稳的；如果图标简单、单色、数量庞大，用iconfont能省心很多，CSS控制颜色大小也非常灵活；如果是现代项目、需要多色图标、希望矢量清晰度和动效能力，SVG Sprite更合适。
再加一句加分总结：“任何技术方案的选择都不是因为技术本身新旧，而是由项目的浏览器兼容范围、图标复杂度和团队维护成本共同决定。”这句话既体现了工程思维，也避免陷入“技术栈高低”的争论。
5.4 面试题模拟：把“性能优化”聊到代码细节
面试官如果让你手写一个雪碧图关键CSS，你最好能一边写一边解释。比如他会给你一个假定场景：一张背景图上，第一行第一个图标在(0,0)，第二行第三个图标在(82,42)，图标尺寸32x32。
你可以写出：
.icon { width: 32px; height: 32px; background: url("sprite.png") no-repeat; } .icon-2-3 { /* 第二行第三列 */ background-position: -82px -42px; }然后主动补充：如果这里图片实际是2x图，还要加一行background-size: 设计稿宽 设计稿高;，否则会糊。顺便提一句“建议每个图标之间留4像素以上padding，避免边缘裁剪问题”。这些细节比单纯背代码更能体现你的实战经验。
面试问答本身就是一次“知识展示”，你越能把原理拆成具体坐标、具体数值、具体场景，越能让面试官相信你有真实项目经验，而不是只会看教程。
最后再多说几句我的实操体会
我从切图切到怀疑人生的阶段走过来，最大的体会是：雪碧图真正难的不是写CSS，而是维护。第一次拼图可能很快，但等到第三个月需要换一个图标时，如果你已经忘了当初坐标系怎么排的，那种痛苦才是最深的。所以我后来无论用什么方案，都坚持先写好一份简单的说明文档，标注清楚图标行列、单元格尺寸、间距和生成命令，后端同事接手也能快速上手。
另外一个实用小建议：新项目如果图标数量不多，优先考虑SVG Sprite或iconfont这些现代方案；但如果接手的是老项目，布局已经用了位图雪碧图，也不必急着推翻，先按照第四节提到的自动化工具把生成流程建起来，后续迭代会轻松很多。还有，记得所有图标按2x尺寸准备素材，哪怕暂时不用totally也不会亏，这算是经验里很实用的一条。
