Placeholder pics 的 SVG 占位图相比普通图片占位方案有什么优势?
Placeholder pics 是一个用 URL 即时生成 SVG 占位图的在线服务。相比传统的位图占位方案（如预先切好的 PNG/JPG 占位图，或本地维护一套占位素材），它的核心优势是：文件体积极小、矢量不失真、无需准备和管理素材、通过 URL 参数即可生成任意尺寸和颜色的图片。如果你的场景是设计稿、原型、开发阶段的临时占位，并且能接受 SVG 格式，它通常比位图方案更省事；如果目标环境不支持 SVG，或需要真实照片质感的占位图，则不适合。
核心差异对比
| 维度 | Placeholder pics（SVG） | 普通位图占位方案 |
|---|---|---|
| 文件体积 | 官方描述为 sub-kilobyte（不足 1KB）、经过优化 | 取决于尺寸和压缩，通常明显更大 |
| 缩放表现 | 矢量格式，任意尺寸都清晰 | 放大会模糊、出现锯齿 |
| 素材准备 | 无需准备，URL 参数即时生成 | 需提前制作、命名、存放 |
| 尺寸调整 | 改 URL 里的宽高即可 | 需重新导出或重新切图 |
| 颜色/渐变 | URL 参数指定，可单色或渐变 | 需重新设计导出 |
| 标签 | URL 末尾可加短标签 | 需在图片上另行标注或命名文件 |
| 格式兼容 | 依赖环境支持 SVG | 位图格式兼容性更广 |
为什么体积和缩放是主要优势
服务说明中明确写到，所有图片都以“sub-kilobyte、完全优化的 SVG”形式提供。这意味着同一张占位图，用 SVG 方案往往只有几百字节级别，而一张普通位图占位图动辄几 KB 到几十 KB。在页面里大量使用占位图时，这个差距会累积成明显的加载负担差异。
同时，SVG 是矢量格式，请求 100×100 和请求 2000×2000 得到的是同一套矢量描述，放大不会失真。位图占位图一旦被拉伸到超出原始尺寸，就会变糊。对于需要在高分屏或不同尺寸下保持清晰的场景，这一点更省心。
无需管理素材，改 URL 就能改图
普通位图方案通常需要：先做图 → 命名 → 放进项目 → 在代码里引用 → 改尺寸时重新导出。Placeholder pics 把这些步骤压缩成一条 URL。
它的 URL 格式规则是：
- 必须以
/svg/开头 - 宽高用
WIDTH x HEIGHT指定，例如/svg/100x100 - 只写一个尺寸时返回正方形，例如
/svg/100返回 100×100 - 背景色可写单个 3 位或 6 位十六进制色值，或用
START - STOP定义渐变 - 前景文字和边框色写在背景色之后，格式为
TEXT - BORDER，且必须先定义背景色 - 标签写在 URL 最后，前景和背景色必须先指定
例如需要一张 100×100、背景 #888888、前景 #EEEEEE 并带标签的占位图，URL 结构就是 /svg/100x100/888888/EEE/My Label。
这意味着调整尺寸、换颜色、加标签都只是改字符串，不需要打开设计工具重新导出，也不需要维护一套占位素材库。
适合与不适合的场景
适合：
- 设计稿、原型、线框图里的临时占位
- 开发阶段接口未就绪时的图片占位
- 需要快速生成大量不同尺寸/颜色占位图的场景
- 对页面加载体积敏感、又需要清晰缩放的项目
不适合：
- 运行环境不支持 SVG
- 需要真实照片质感或复杂视觉的占位图
- 需要长期稳定托管、对第三方服务可用性有要求的正式生产素材
使用前需要知道的限制
服务以“as is”形式提供，官方声明不附带准确性或可访问性方面的明示或暗示保证。因此它更适合临时、非关键的占位用途，而不是作为正式生产环境的关键依赖。另外，标签应保持简短，并考虑所请求图片的尺寸——图太小、标签太长会显示不下。
如果你的项目能接受 SVG，且占位图只是过渡性质，Placeholder pics 在体积、缩放和素材管理上都比传统位图方案更轻；如果这两点不成立，继续用位图占位更稳妥。