SVG 二十五年：一种被低估的图形语言的前世今生

2025 年底，一位开发者在博客里写了句话：「我 2005 年写的 SVG，20 年后仍能正确渲染。我不确定我当时写的其他东西——不做些编辑——还能不能用。」

这不是孤例。在 Hacker News 一条《An SVG is all you need》的帖子里，好几个老开发者都讲过类似经历：一个 20 年前手写的 <svg> 文件，拖进今天的 Chrome、Safari、Firefox，画面该什么样还是什么样。

这件事在软件世界里挺罕见。20 年前的 Flash 动画今天打不开，20 年前为 IE6 写的 ActiveX 早成电子文物。但一个基于开放文本标准的矢量图形，穿越了四分之一个世纪的浏览器战争、移动革命、AI 浪潮，原样活了下来。

这种长寿不是偶然，它来自 SVG 诞生时一个相当固执的设计选择。我们得回到 1996 年，看这个选择是怎么做出来的。

一个被反复低估的事实：SVG 是文本，不是图片

讲历史之前，先把最核心的判断摆出来。

SVG（Scalable Vector Graphics，可缩放矢量图形）是 W3C 在 2001 年制定的一项开放矢量图形格式标准，它用 XML 文本来描述图形，让一张图既能像照片一样被浏览，又能像程序一样被读取、修改和生成。

这句话里藏着 SVG 最容易被忽视的一个属性——它是「文本」。这一条决定了它过去 25 年几乎所有的命运：为什么它打不过 Flash 却活到了现在，为什么它的标准推进得这么慢，以及为什么它在大模型时代突然迎来了第二春。

回过头看，SVG 在 25 年里赢了两场歼灭战（Flash、icon font），输了一场局部战（SVG 字体），还熬过了 IE 的十年封锁。它从来没有被任何一个对手真正取代过。这是个相当惊人的记录。

1998 年的六国大战

1996 年的 Web 还是个文字为主的世界。图片是有的，但几乎全是 GIF 和 JPEG——位图。位图能还原照片，但放大就糊，文件还大。对一个正拼命往「富应用」方向跑的 Web 来说，缺一种能在任何分辨率下都清晰、文件又不大的图形格式。

W3C 的 Chris Lilley 这一年写了一份《矢量图形通用需求》文档。这个名字后面会反复出现——他是 W3C 的长期员工、图形活动负责人，从 SVG 还是个想法开始一直到现在都是工作组的关键人物。

到了 1998 年，事情热闹起来了。W3C 一口气收到 6 份竞争性的矢量图形提案，像诸侯讨董卓：Web Schematics、PGML、VML、HGML、WebCGM、DrawML。

六份里真正有分量的是两份——PGML 和 VML。它们背后的阵营，几乎划定了未来十年 Web 图形的权力版图。

PGML（Precision Graphics Markup Language）由 Adobe 牵头，拉上 IBM、Netscape、Sun。它的技术底子是 Adobe 自家的 PostScript 和 PDF 成像模型。也就是说，PGML 生来就带着印刷出版世界几十年积累的矢量数学：贝塞尔曲线、坐标变换、色彩空间、字形处理，都是成熟的。Adobe 一方的态度很开放——明确表示 PGML「只是个提案，W3C 可以任意修改它」。

VML（Vector Markup Language）由 Microsoft 牵头，拉上 Autodesk、HP、Macromedia。它来自微软 Office 团队，最早是 PowerPoint 的一个附加组件。VML 一方的态度截然相反——微软声称 VML「是已发布产品的文档，W3C 无权做任何修改」。

这句话暴露了 1998 年微软的心态。这家公司当时正处在 IE 击败 Netscape 的巅峰期，把 Web 标准当成自家产品的延伸。两种态度的后果，在后面的标准谈判里彻底显现。

另起炉灶：SVG 的出生证

面对六份提案，W3C 没有简单选边。1998 年，它决定正式成立 SVG 工作组，并做了一个关键决定：不采用任何一份现有提案，而是从头设计一门全新语言。

这个决定是双赢的。技术上，工作组可以把各家最好的部分拼起来——VML 贡献了紧凑路径语法（催生了 SVG 标志性的 <path d="..."> 微语法），PGML 贡献了坐标系、变换、色彩空间、文本和字体处理。政治上，「另起炉灶」化解了微软「W3C 无权修改 VML」的死结。

两位核心推动者必须记一笔。Chris Lilley（W3C），从 1996 年的需求文档到今天，贯穿了 SVG 所有版本。Jon Ferraiolo（IBM，后转 Adobe），SVG 1.0 规范的首席编辑，是 SVG 的主要架构师之一。

2001 年 9 月 4 日，SVG 1.0 正式成为 W3C Recommendation。 它的设计目标相当克制：基于 XML 描述二维矢量图形，核心特性包括矢量形状、路径、文本、渐变、图案、裁剪与蒙版、滤镜、交互性、动画。

如果你只看这份特性清单，会觉得 SVG 出生即巅峰。但真实情况是，它发布之后的整整十年，过得相当憋屈。原因只有一个字：IE。

暗黑十年：等一个浏览器

SVG 1.0 成了标准，但标准是纸面上的事。Web 上的图形能不能显示，取决于浏览器实现。而 2001 年的浏览器版图是这样的：Internet Explorer 是绝对霸主，市场份额超过 90%；IE 完全不支持 SVG，一直到 IE8。

这是 SVG 早期命运坎坷的根本原因。一个 Web 标准，最大的浏览器不支持，它就只能活在「准存在」状态。

这段时间支撑 SVG 不至于消失的，是两个东西。第一是 Adobe SVG Viewer（ASV），Adobe 自己做的浏览器插件，W3C 官方记载它是「最健壮、最快的实现之一」。换个角度看，SVG 在 2001 到 2008 这段日子，是靠 Adobe 这个娘家续命的。第二是一些边缘浏览器的先锋——冷知识：第一个原生渲染 SVG 的浏览器是 Konqueror（3.2 版，2004 年 2 月），不是 Firefox，不是 Safari。Opera 在移动 SVG 上是真正的先锋。

但这些「先锋」的市场份额加起来，在 IE 面前都可以忽略。SVG 在 Web 上真正能用，得等到 2011 年 3 月 14 日 IE9 发布，微软终于引入了基础 SVG 支持。

从 2001 到 2011，整整十年。这十年里，开发者提到 SVG 最常用的形容是「the future of web graphics」——听起来像夸奖，其实是死刑判决：既然是「未来」，那现在就用不了。一个被反复推迟的「未来」，慢慢就没人信了。

这段「等 IE」的十年，是理解 SVG 后来所有决策的心理背景。它解释了为什么 SVG 工作组在 2004 年会有那么离谱的野心，也解释了为什么 SVG 2 到今天还停在 Candidate Recommendation——这个标准被耽误太久了，以至于它既急于证明自己，又对「再做大动作」充满创伤性的谨慎。

野心的代价：差点塞进 raw socket 的 SVG

SVG 历史上最离奇的一段故事，发生在 2004 年前后。

移动设备崛起，3GPP 把 SVG Tiny 采纳为下一代手机的强制矢量图形格式。工作组在膨胀的乐观里，开始规划下一个大版本：SVG 1.2 Full。

它的野心大到今天读起来像段子。它不满足于做一个图形格式，想做一个完整的应用运行时。最能说明问题的，是 2004 年的 W3C 工作草案里有一段提议：SVG 文件应该能通过 raw socket（原始网络套接字）与任何专有协议或非 HTTP 端点通信。提案者的目标直指桌面系统——他们想让一个 .svg 文件直接发起 TCP 级别的网络连接。

草案里有一句相当坦诚的自问自答：「除了常识之外，有什么阻止我们在 .svg 文件中开发完整应用？」

答案当然是常识。2004 年恰好是 Internet Explorer 最黑暗的一年——接连爆出远程代码执行漏洞，浏览器安全环境已经烂到没法收拾。在这种背景下给一个能在浏览器里跑的图形格式塞 raw socket，等于在火药桶上点烟。

SVG 1.2 Full 草案的最后一份 Working Draft 停在 2005 年 4 月 13 日，之后工作「明显被放弃」。只有一个小个子活了下来——SVG Tiny 1.2，在 2008 年 12 月成为正式 Recommendation。

SVG 1.2 Full 失败的原因是好几个叠在一起：过度宏大（想把声明式图形、交互逻辑、应用 API 全塞进一个标准）、和 HTML5 的权力之争（浏览器厂商的精力转向 HTML5）、流程争议（WHATWG 的 Ian Hickson 公开批评 W3C 推进流程）。

这段故事对 SVG 的心理创伤很深。它直接决定了 SVG 2 的设计哲学——不再追求「大而全」，而是转向「和 HTML5/CSS 深度集成」。工作组学乖了：与其和 HTML5 抢地盘，不如把 SVG 的特性拆出去，让 CSS 工作组去维护。Transforms、Filters、Masking 这些原本属于 SVG 的东西，在 SVG 2 里被正式移交给了 CSS 模块。

这是一个标准的「创伤后转向」。被 raw socket 事件和 1.2 Full 的失败吓到之后，SVG 变得极度收敛。这种收敛保住了它的命，但也埋下了 SVG 2 至今难产的种子。

转折点：被 HTML5 收编

就在 SVG 1.2 Full 死掉的 2005 到 2007 年间，一件对 SVG 命运至关重要的事悄悄发生了：SVG 被内嵌进了 HTML。

在此之前，要用 SVG，得用 <object>、<iframe> 或者独立的 XML 命名空间去引用它，像一个外挂组件。inline SVG 改变了这一切。到 2007 年 11 月，它已经是公认的概念。技术上的实现相当精巧：HTML5 解析器在遇到 <svg> 标签时，会自动切换到 SVG 命名空间去解析。

这件事的意义怎么估计都不过分。它意味着 SVG 不再是「需要被嵌入的外部资源」，而是 HTML 文档的一部分。一个 <svg> 标签可以和 <div>、<p> 平起平坐地写在页面里。更重要的是，SVG 的每个元素都成了 DOM 节点，可以用 CSS 样式化、用 JavaScript 操作、用屏幕阅读器读取。

这是一个关键的认知转变。在此之前，SVG 的竞争对手是 Flash——两者都是「插件式」的存在。inline SVG 之后，SVG 的定位变成了「Web 原生的矢量能力」。它不再需要打败 Flash，因为 Web 标准阵营（HTML5/CSS3/Canvas/WebGL/SVG）会一起绞杀 Flash。

同一时期，WHATWG 还梳理了 SVG 和 Canvas 的分工，这份梳理今天看仍然准确：SVG 是保留模式（retained mode），维护一棵场景图，每个图形是 DOM 节点，浏览器负责重绘，天然支持交互和无障碍；Canvas 是立即模式（immediate mode），拿到画布后用 JS 直接画像素，画完即忘，性能更高但不记得自己画了什么。两者在 HTML5 里是互补的，不是竞争。

下面这张图把两种模式的核心差异和取舍讲清楚了：

这个「被 HTML5 收编」的决策，要到十几年后才完全显现它的长期回报。当大模型开始生成代码的时候，「SVG 是 HTML 的一部分」意味着 LLM 可以像写 <div> 一样自然地写出 <svg>。

Flash 的死，与 SVG 的继承

Flash 是 SVG 诞生时最大的对手。但这场胜利的解读，远比「开放标准打败闭源插件」复杂。

先承认一件事：在 2000 年代，SVG 根本打不过 Flash。 那时候的 Flash 把矢量动画、交互、视频三件事打包在一个插件里，是 HTML4 和 CSS2 完全做不到的。YouTube 早期用 FLV 传视频，横幅广告、网页游戏几乎全是 Flash。在浏览器标准分裂的年代，一个插件保证了「处处相同」——开发者只要为 Flash Player 写一次，所有浏览器表现一致。

SVG 拿什么打？它有开放标准，但 Flash 有市场占有率。最致命的是，IE 不支持 SVG——一个用 SVG 的网站，在超过 90% 的浏览器上是看不到的。

那 Flash 是怎么输的？不是输给 SVG，是输给了它自己。

Flash 衰落的根因是多个因素叠加。安全漏洞泛滥，成了恶意软件的首要攻击目标。性能和功耗灾难，CPU 占用高、耗电，乔布斯那封《Thoughts on Flash》公开信里原话就说 Flash 是 Mac 崩溃的头号元凶。插件模型的反 Web 哲学，一个需要用户下载安装、在浏览器沙箱外运行的二进制插件，和开放 Web 标准根本对立。

致命一击来自移动时代。2010 年乔布斯公开宣布 iOS 永不支持 Flash，2011 年 Adobe 砍掉移动版 Flash，实质投降。2015 年 Chrome 默认暂停 Flash，2017 年 Adobe 宣布 Flash 2020 年终止支持，2020 年 Flash Player 正式停用、浏览器全面移除。

把这条时间线和 SVG 的命运叠起来看很有意思。Flash 死亡的每一步，SVG 都在相应地获得新生命：2011 年 IE9 上线原生支持 SVG，恰好是 Adobe 砍掉移动 Flash 的那一年；2014 年 SVG 图标开始系统性取代 icon font，恰好是 Flash 在 Chrome 里被默认暂停的前夜。这不是巧合——整个 Web 行业在从「插件时代」迁向「原生标准时代」，SVG 是这场大迁徙里矢量图形这一垂直赛道的法定继承者。

SVG 在这个衰落过程里扮演的角色很有意思。它不是单挑打赢了 Flash——单挑它根本打不过。它是「开放 Web 标准阵营」的一员，和 HTML5、CSS3、Canvas、WebGL、<video> 一起，共同绞杀了封闭插件。但 SVG 是这个阵营里矢量图形这一垂直领域的法定继承者。

有个细节值得记下。Google 当年做了一个叫 Swiffy 的工具，直接把 SWF 文件转成 HTML5——用 SVG 画图形、用 JS 做动画。Swiffy 是 Flash 向 SVG 迁移的标志性桥梁，它证明了 SVG 在功能上能覆盖 Flash 的大部分矢量场景。

社区对 Flash 时代的评价很有感情。独立游戏开发者 Nathalie Lawhead 把 Flash 时代称为「网站的黄金创作期」。但哪怕是这些怀念 Flash 的人，也没人想回到插件模型。这是开放标准对闭源生态的一场心理胜利——不是「Flash 不好用」，而是「插件模型本身是错的」。

一场干净的胜利：干掉 icon font

2010 年代初，Web 上的图标几乎全是 icon font——图标字体。Font Awesome、icomoon 是统治级方案。原理是把图标做成一套字体，每个图标对应一个 Unicode 码位，用 <span class="icon-home"></span> 插入，靠 color 和 font-size 控制颜色和大小。

icon font 能流行，是因为它解决了当时的真问题：一次性 HTTP 请求、浏览器兼容到 IE6。但它的毛病，随着高 DPI Retina 屏和多色品牌图标的普及，变得越来越不可忍。

2014 年，Chris Coyier 在 CSS-Tricks 发了《Icon Fonts vs SVG》，成了 SVG 图标取代字体图标的标志性文章。他逐项对比，结论是「只要能上 IE9+/Android 3+，inline SVG 几乎在所有方面都更好」。

几个关键差异很能说明问题。渲染质量：字体图标被浏览器当「文字」抗锯齿，小尺寸和高分屏上容易糊；SVG 是纯正矢量，无限缩放零损耗。定位：icon font 最让人崩溃的地方——它的包围盒受 line-height、vertical-align、字形设计牵制，经常和容器对不齐；SVG「就是它本身的大小」，高度可预测。失败状态：字体文件加载失败是家常便饭，一旦失败要么空白要么显示成乱码 Emoji；inline SVG 就在文档里，没有「加载失败」这个状态。CSS 控制：字体图标只能改一个 color（单色）；SVG 可以针对不同部件分别样式化，做多色图标和图标动画。

转折点是 2014 年前后 Windows XP 退役、IE8 退场。一旦浏览器兼容不再是障碍，SVG 图标的优势全面压倒。SVG 在图标领域完成了全面替代。 Font Awesome 后来也推出了 SVG 版本，今天所有主流图标库默认就是 SVG。

有人总结过一个很妙的框架，叫「SVG 三角妥协」：SVG 图标方案有三个互相竞争的属性——可样式化、可缓存、有内在尺寸，你最多只能同时满足两个。inline SVG 满足「可样式化 + 有尺寸」但牺牲缓存；外部 <img> 满足「可缓存 + 有尺寸」但不能用 CSS 改色。结论是 <svg> + <use> 引用外部 <symbol> 是唯一能同时满足三者的方案，代价是跨域限制等一堆真实痛点。到了 2023 年，社区又往前走了一步——转向 inline SVG via 组件系统（react-icons、lucide-react），配合 tree-shaking 控制体积。

先记住这个三角结构，三种方案各据一边，唯一的三者兼顾方案在中心。

D3 与三大领域的统治

图标的胜利之外，SVG 还在另外两个领域完成了事实占领——数据可视化和地图。这两个领域的命运转折点，都和一个库有关。

D3.js（Data-Driven Documents）2011 年由 Mike Bostock、Jeff Heer、Vadim Ogievetsky 在 Stanford Visualization Group 发布（前身是 2007 年的 Protovis），基石论文发表在 IEEE InfoVis 2011，被引超过 4900 次。D3 的本质是一个 DOM 操作库，SVG 是它的原生载体——它把数据绑定到 DOM 节点上，每个数据点对应一个独立的 SVG 元素，可以绑定事件、精确样式化、做无障碍。

这套范式彻底改变了 Web 数据可视化。在 D3 之前，做交互式图表要么用 Flash，要么用笨重的商业图表库。D3 加 SVG 让「定制化、交互式、Web 原生」的可视化成为可能。Mike Bostock 后来去《纽约时报》做图形编辑，D3 加 SVG 成了新闻类交互图表的事实标准。

地图领域也类似。Leaflet 是最流行的开源地图库之一，它提供两个渲染器类：L.SVG（现代 Leaflet 的默认）和 L.Canvas（数千个特征时性能更好）。SVG 是地图标注的默认载体——每个标注是独立 DOM 节点，可以绑定点击事件、可以悬停高亮。SVG 2 专门给 symbol 加了 refX/refY 属性，就是为了地图和数据图表的精确定位。

但 SVG 在数据可视化里也有明确的性能天花板。社区共识是：1000 个元素以内 SVG 顺畅；1000 到 5000 开始可感劣化（尤其动画和交互）；超过 5000 通常要改用 Canvas 或 WebGL。 有人测过 D3 图表在动画 30000 个元素时性能急剧下降，社区的标准建议就是「那么多元素放 SVG 里肯定不行」。这是 SVG 保留模式的根本代价——每个元素都是独立 DOM 节点，带来完整的 DOM 开销。把这三个领域放一起看，会发现一个共同模式：SVG 在「中小规模、高交互、需要无障碍、需要 CSS 样式化」的场景里，是没有对手的。 它的统治不是来自性能（性能反而是它的短板），而是来自那个 1998 年就定下的设计选择——它是文本，是 DOM，是 Web 原生的。

罕见的退让：SVG 字体

讲完干净的胜利，讲一个 SVG 罕见的「收缩」。

SVG 1.1 里其实定义了一套字体方案——<font>、<font-face>、<glyph> 元素，允许把字形作为 SVG 路径内嵌。早期移动 Web 它是个权宜之计：iPhoneOS 3 到 iOS 4 的 Safari，自定义 Web 字体几乎只能用 SVG 字体。

但 SVG 字体天生残缺——没有 hinting，没有实用的 kerning，不支持连字，处理不了复杂文字。文件还不压缩，特别大。更要命的是，SVG 字体可以包含脚本和任意矢量图形，引发了一堆安全和性能担忧。

真正埋葬 SVG 字体的是 WOFF（Web Open Font Format）。2009 年 4 月开发，2010 年 3 月 Mozilla、Opera、Microsoft 联合向 W3C 提交 WOFF 1.0——平时互相掐的三家，在「干掉 SVG 字体」这件事上出奇一致。2018 年 WOFF 2.0（用 Brotli 压缩，比 1.0 又小 30%）接力。

SVG 字体的退场是有顺序的：iOS 5（2011）弃用，Chrome 38（2014）移除。在 SVG 2 规范里，字体元素被正式移除。

SVG 在「字体」上输了，但它在「图形」上赢麻了。 这其实是好事——SVG 字体本来就是个四不像，交给专门设计的 WOFF 是各归其位。这是 SVG 25 年里少数明确的领域收缩。

SVG 2：那个至今没跨过的坎

时间来到 2010 年代。SVG 1.2 Full 死了，SVG 1.1 还在用，工作组决定启动 SVG 2。

它的设计哲学是被 1.2 Full 的失败吓出来的「收敛」：不和 HTML5 抢地盘，而是深度集成。把几何属性（x、y、d 等）变成 CSS 属性；允许 HTML 元素直接放进 SVG；把原本属于 SVG 的 Transforms、Filters、Masking 拆给 CSS 工作组维护。还加了一堆新东西：meshgradient（二维任意形状渐变）、所有元素的 z-index、symbol 的 refX/refY（专门为地图和数据图表的精确定位设计）。

听起来很美好。但 SVG 2 的命运，成了 SVG 25 年里最漫长的等待。

2016 年 9 月 15 日，SVG 2 第一次成为 Candidate Recommendation。 W3C 规范原文当时乐观地写：「本候选推荐标准预计最早将于 2018 年 12 月 4 日推进至 Proposed Recommendation。」

这个推进从未发生。

最后一份官方 CR 快照冻结在 2018 年 10 月 4 日。从那以后，SVG 2 的「正式标准」就停在这里没动过。为什么会卡住？2024 年 4 月的 W3C SVG 工作组章程里有一句关键原话：

「SVG2 在推荐标准轨道上向后续阶段推进，取决于该小组参与度的提升。」

翻译成人话：没人干活了。当前章程（主席是 Adobe 的 Dirk Schulze）明确写了「不引入新功能，也不孵化新提案」，重心是「核心 SVG 规范的维护与互操作性测试」。SVG 2 的预期完成日期标注为「未定」。GitHub 上的「SVG 2.0 Proposed Recommendation」里程碑，至今还是 Open 状态。

这是标准化世界一种很特殊的困境：规范写出来了，技术上也成熟了，但没有足够的人力和意愿去走完那段流程。SVG 2 不是「失败」，它是「悬置」。

这种悬置的现实后果是：事实标准和规范标准长期割裂。浏览器实际实现的，是 SVG 1.1 + 一部分 SVG 2 草案特性的混合体。哪些 SVG 2 特性能用，取决于各家浏览器的实现进度，而不是规范怎么说。Tavmjong Gel 的 SVG 2 状态页长期追踪这件事，说到底是在替规范做它没做完的活。

还有一个有意思的细节，叫「at-risk features」（风险功能）。SVG 2 的 CR 里列了一批可能在候选期间被砍的功能：支持多个 title/desc 做本地化、zoomAndPan 属性、嵌套链接、unknown 元素。这些功能被标为「at-risk」，意思是「我们也不确定能不能保住」。一个标准连自己的特性都保不住，这本身就说明了它的处境。

SMIL：那个「已死却活着」的动画系统

讲 SVG 的悬置，就不能不讲 SVG 动画里最戏剧化的一段——SMIL 的废弃闹剧。

SMIL（Synchronized Multimedia Integration Language）是一套声明式动画规范，SVG 从 1.0 起就内嵌了它的一个子集。你可以用 <animate>、<animateTransform> 这些标签，不写一行 JavaScript 就让 SVG 动起来。

2015 年，Chrome/Blink 团队发了一份「Intent to Deprecate: SMIL」，宣布打算废弃它，理由是 CSS 已经能做 SVG 动画了。这份废弃意图在开发者社区炸了锅——SMIL 当时被广泛使用，尤其是那些不想引入 JavaScript 依赖的纯声明式动画场景。

开发者的反对声浪大到 Chrome 在 2016 年底暂停了废弃，并且之后再也没执行过。到 2025 年，SMIL 的 SVG 动画在 Chrome、Firefox、Safari 全部存活，使用量反而涨到了近 2.5% 的页面加载量。Smashing Magazine 在 2025 年 5 月写了一句很妙的调侃：

「SMIL 已死。然而它活得好好的，因为 Google 几乎在十年前撤销了废弃决定。」

这是「事实标准打败规范意图」的经典案例——Google 想用规范权力废弃它，开发者用实际使用把它保了下来。

WebKit 的十年技术债

SMIL 的故事是「规范意图 vs 事实标准」的割裂。还有一种割裂更隐蔽——引擎实现差异。讲一个特别能说明问题的案例：WebKit 的 SVG 引擎，背了十多年的技术债。

WebKit 旧的 SVG 渲染引擎有个根本性的硬伤：它完全游离于浏览器的硬件加速体系之外。HTML 和 CSS 早就用一套叫 Layer Tree（图层树）的机制做合成加速，把页面拆成多个图层交给 GPU 合成，动画时只重绘变化的图层。但旧 SVG 引擎不在这套体系里——动画时被迫每帧重绘大块页面、重复 layout。

更离谱的是，<foreignObject> 这个元素，WebKit 15 年没有正确实现。它是 SVG 里用来嵌入 HTML 内容的元素（比如在 SVG 里放一个 <div>），本来是为了让 SVG 和 HTML 能混排。但 WebKit 的 Layer Tree 无法和 SVG 子树交互，导致 foreignObject 长期不工作。还有 CSS z-index、3D 透视变换、任意 SVG 元素的覆盖矩形计算，统统缺失。改一个 transform 会触发整个 re-layout。

这个技术债的修复，是一个叫 LBSE（Layer-Based SVG Engine）的项目。由 Igalia 的 Nikolas Zimmermann 主导，出资方是 Vorwerk——德国那家做 Thermomix 厨师的厂商。他们用 WPE WebKit 做嵌入式 UI，重度依赖 inline SVG 加 CSS 动画，桌面浏览器上跑得流畅，但目标硬件上「性能太慢，远不可用」。于是 Vorwerk 出钱，Igalia 出人，2019 年 10 月启动，2022 年 12 月主要架构改动合并进 WebKit。

这个故事说明：SVG 的「标准成熟」和「实现成熟」是两件事。一个标准可以写得很完善，但如果主流引擎的实现长期有结构性缺陷，那开发者的真实体验就是有缺陷的。WebKit 的 SVG 技术债拖了十几年，影响的几乎是所有 iOS 用户（因为 iOS 只能用 WebKit 引擎）——这是移动时代 SVG 体验时不时拉胯的隐藏原因。

除了这种大的结构性问题，引擎之间还有一堆小的渲染分歧。比如 bounding box（包围盒）的计算：当一条 path 的控制点超出路径本身时，Firefox 和 Inkscape 的算法算出来「更合理」，WebKit 的算法不一样。开发者用这个差异，靠「相对 path bounding box 的渐变」来隐藏文字，结果在不同引擎里显示完全不同。

还有一个更基础的问题：SVG 的数值精度。开发者在 Hacker News 上深挖过，SVG 的「安全数值范围」实际只在 2e3 到 2e5 之间。有人想做一个「1 单位 = 1 秒」的日时间轴（86400 秒），Firefox 和 Chrome 都渲染不对，只能被迫缩小数值。更夸张的是，有人 2008 年做过一个卫星轨道 SVG，按 1:1 比例，图像宽 84000 公里——大量查看器直接噎住。「SVG 里的『可缩放』也就这么回事。」这是一句很扎心的吐槽。

安全的暗面：它从来不是图片格式

讲到 SVG 的怪癖，必须提一个被严重低估的问题：安全。

社区里有一句被反复引用的话：「SVG 从来不是图片格式，它是标记语言。」

这句话的分量，要在你看过 SVG Clickjacking 攻击之后才能真正体会。2025 年 12 月，安全研究员披露了一种攻击手法（Google 为此付了 3133.70 美元赏金）：利用 SVG 的滤镜原语——<feTile>、<feComposite>、<feColorMatrix>、<feDisplacementMap>、<feImage>——对跨域 iframe 做像素级读取，可以构建出 AND、OR、NOT、XOR 逻辑门，完全在 SVG filter 内做条件编程。

这意味着 SVG 的滤镜系统，骨子里是一个图灵完备的像素处理语言。

更深层的认知来自 2026 年 4 月的另一篇热帖。作者指出 Google Slides 至今不支持 SVG，尽管有近 15 年的用户请求工单——就是因为「净化 SVG 太难了」。SVG 可以内嵌脚本、可以加载外部资源，要把一个不可信的 SVG 安全地展示出来，在技术上极其复杂。

Hacker News 上有一条高赞评论点破了真相：「SVG 明显有两类：一类是『一堆带 fill 的 path』，占真实使用的大多数；另一类是『聪明危险的东西』。规范把两者混在一起，导致你没法只支持前者。」

更关键的是，SVG 的安全行为取决于它怎么被嵌入。用 <img src="...svg"> 嵌入，浏览器会自动剥离脚本——相对安全。但用 <object> 或 inline <svg> 嵌入，脚本和外部引用都会执行——「人们用 <img> 测试觉得没问题，换个嵌入方式就全开了。」

这个安全问题在 AI 时代变得格外尖锐。当大模型开始大量生成 SVG，这些 SVG 会被成千上万的网站嵌入、被用户复制粘贴。一个能内嵌脚本的「图片格式」，在供应链层面是个巨大的攻击面。这是 SVG 作为「标记语言」而非「图片格式」的根本代价。

横向看：SVG 在竞争图谱里的位置

把镜头横过来，看看 SVG 在同期竞争里到底是个什么位置。

过去 25 年，它先后遭遇了五波性质不同的竞争者，每一波的处理方式都不一样。

第一波，直接竞争者（Flash、VML）。 Flash 2020 年彻底死亡，SVG 继承矢量职能。VML 随 IE 陪葬，只剩 Office 遗留和 Outlook 邮件里的幽灵。VML 的故事比 Flash 更有警示意义——它输给 SVG 不是输在技术，是输在微软的战略姿态。「W3C 无权做任何修改」那句话，把 VML 钉死在了「厂商私货」的位置上。一个 Web 格式的命运，往往不取决于它的技术能力，而取决于它背后的厂商愿不愿意放手。

第二波，分层互补者（Canvas、WebGL/WebGPU）。 这是最经典的一组对比。SVG 是保留模式，Canvas 是立即模式。实测数据告诉我们：两者在约 10000 个图形元素之前性能接近，超过后 SVG 因 DOM 开销（reflow、repaint、事件监听、样式解析）急剧退化。实践中的保守建议是 3000 到 5000 个元素就该切到 Canvas，WebGL 能到数十万甚至上百万。

为什么会这样？因为 SVG 的「每个图形都是 DOM 节点」是个双刃剑。它带来了交互、样式化、无障碍的所有好处，但每个节点都有完整的 DOM 开销——事件监听器、属性对象、样式解析、布局计算。10000 个节点意味着 10000 份这种开销。Canvas 没有这个问题，因为它根本不维护节点，只维护一块像素缓冲。

社区的经验法则很实在：先用 SVG，到 3000-5000 个元素或需要实时大量动画时切 Canvas，要 3D 或海量数据时切 WebGL。这是一个「按需上移」的分层策略，不是谁取代谁。但迁移迹象是明确的——数据可视化领域，deck.gl、ECharts、Plotly、Highcharts 的 boost 模块这些大场景库默认走 Canvas/WebGL。Mapbox GL JS 早就用 WebGL。甚至连 D3 生态也在分化——纯 D3 还是 SVG，但基于 D3 思想的高性能库（如 deck.gl）走的是 WebGL。SVG 守住了「中小规模、高交互」的下层，Canvas/WebGL 占据了「大规模、高性能」的上层。这个上限是 2001 年保留模式架构选择的直接后果，无法靠优化克服。

第三波，井水不犯河水者（PDF、WebP/AVIF）。 PDF 统治印刷，SVG 是 Web 冠军，差异是结构性的——PDF 用 CMYK，SVG 主要用 RGB；PDF 原生支持多页和印刷特性，SVG 在这些方面很有限。WebP/AVIF 是位图，SVG 是矢量，根本不是一个物种。

第四波，上游依赖者（Figma、Sketch、Illustrator）。 它们不是 SVG 的竞争者，而是 SVG 的依赖者和质量上的拖累者。核心问题是设计工具导出的 SVG 普遍臃肿，严重到催生了 SVGO（SVG Optimizer）整个工具生态——典型效果是清理设计工具导出的文件减小 30-70%。这形成了一条标准流水线：设计工具导出 → SVGO 清理 → 上线。这件事本身说明了一点：SVG 作为开放文本格式，允许第三方工具介入清理。这是位图格式不可能有的生态。

第五波，AI 时代的新物种。 这里有三种性质完全不同的存在，必须分开看。

AI 时代：SVG 迎来第二春

现在，故事来到了 2024 到 2026 年。这是 SVG 25 年历史上第二次重大的命运转折——第一次是 inline SVG 被收进 HTML5，这一次是它被大模型重新发现。

要理解为什么 SVG 在 AI 时代突然重要，得先理解那句话：SVG 就是代码。

它不是一堆像素，而是一段 XML 文本，描述了图形的结构。这意味着，生成 SVG 这件事，和生成代码是同一类问题。这恰好是大模型最擅长的事。

最早的探索是学术界的。DeepSVG（2020 年）把 SVG 路径表示成一串命令序列，第一次系统性地证明了「SVG 是可以被深度学习生成和推理的矢量表示」。IconShop（AAAI 2024）把文本引入了这个游戏，用扩散模型从文字提示生成 SVG 图标。

真正把这件事推到工程层面的是 StarVector（CVPR 2025）。它的核心洞见，用论文标题说得很直白：「Generating Scalable Vector Graphics Code from Images and Text」——把矢量生成重新定义成一个代码生成问题。架构上，它用 CLIP 视觉编码器把图像投影成视觉 token，再接一个基于 StarCoder（CodeLLM）的代码生成器，自回归地输出 SVG 代码。它会精确地使用椭圆、多边形、文字这些绘图原语，而不是只会用曲线拟合。

为了训练，作者整理了 SVG-Stack 数据集——从 GitHub 公开仓库里挖出的 200 多万个真实 SVG 样本。还提出了 SVG-Bench，指出传统的像素指标（MSE）根本不足以衡量矢量图形的质量。这是评估层面的一个重要纠偏。

但 StarVector 的 README 里有一句诚实的话：「StarVector 模型不适用于自然图像或插画。它们在矢量化图标、logotype、技术图表上表现出色。」这是个重要的能力边界——它擅长的是「结构化、语义清晰的图形」，不是「氛围感插画」。

更贴近普通开发者的是通用大模型直接写 SVG。Simon Willison 做过一个很有名的 benchmark，叫「鹈鹕骑自行车」（Generate an SVG of a pelican riding a bicycle），用来横向比较各模型的 SVG 生成能力。他选鹈鹕有两个原因：他喜欢鹈鹕；想避免训练数据污染。

截至 2025 年 11 月，他的结论是：Gemini 3 Pro 画得最好，但他有一句总评很关键——「最好的模型画出的鹈鹕骑自行车，依然可笑地糟糕。」

这指向一个根本问题：通用 LLM 在 SVG 上「时灵时不灵」。LLM4SVG（CVPR 2025）这篇论文诊断得很准——LLM 把 SVG 源码当成纯文本来处理，而不是结构化的空间表示，导致几何推理能力差。具体表现是：生成时丢失细粒度细节，难以表达非刚性变形，无法规划多元素空间关系，常见「形状扭曲和不完整」。原因之一是大多数 LLM 的 tokenizer 把数字压成单个 token，处理连续数值时会失败；模型默认用整数和基本颜色名（如「blue」），而不是小数坐标和十六进制色值。

LLM4SVG 的解法是定义一套 55 个 SVG 语义 token（15 个 tag、30 个 attribute、10 个 path command），让模型理解 <path> 是一个绘图指令而不是文本里的「path」这个词。基于这套 tokenization，它构建了 25 万高质量矢量图加 58 万 SVG-text 指令对，两阶段训练后，基于 GPT-2 XL 的 LLM4SVG 在视觉指标上超过了 GPT-4o、Claude 3.5、Gemini 1.5 Pro。

社区里有一个很聪明的实践策略：不直接让 AI 写原始 SVG，而是让 LLM 输出 JSON 数据再经 D3.js 渲染，可以获得一致的 SVG 结果。这是用「LLM 擅长的（数据结构生成）」去弥补「LLM 不擅长的（几何代码生成）」，相当务实。典型项目有把名画重绘为 SVG 的实验、AI 实时流式返回 CSS @keyframes 的 SVG Weave 节点图编辑器、生成 PNG 图标后用第二个模型矢量化的 IconPackGen 两步法。

这些细节指向同一个判断：SVG 作为「可生成、可推理的结构化矢量表示」，在 AI 时代有独特的位置。 位图 AI（Midjourney、Stable Diffusion）擅长的是「氛围感、照片级、不可编辑的成品图」，SVG 擅长的是「结构化、可编辑、可语义化推理的设计资产」。两者产出的是完全不同的东西。

Hacker News 上有一条高赞评论把 SVG 在 AI 时代的独特价值说得很透：「SVG 是用一种语言写成的；LLM 擅长操作语言。你可以通过指定 SVG 元素来和 AI 沟通——『把 ID 为 logo 的元素旋转 30 度』——这种指令对 AI 非常易读。」位图做不到这一点。你没法对 Midjourney 说「把我刚才那张图里左下角的圆挪到右上角」——但你可以对一个能读写 SVG 的 Agent 说这话，而且它能听懂、能执行。

这是 SVG 在 25 岁这年，意外获得的一张新底牌。

如果你只想先抓主线，可以先看下面这张图，把 25 年的关键节点串起来再看后面的总结。

历史如何塑造了今天

把纵向和横向叠在一起，最核心的判断只有一个。

SVG 能在 25 年里打赢 Flash、干掉 icon font、熬过 IE 的十年封锁、扛住 Canvas/WebGL 的蚕食，最后在 AI 时代迎来第二春，根本原因不是它技术最强，而是它从出生那天起就选了一个独特的定位——它是文本，是代码，是 Web 原生的标记语言，而不是一个图片格式。

这个定位的回报，在 25 年里分四次兑现。第一次是 inline SVG 被收进 HTML5，让它获得了 DOM、CSS、JavaScript 的全部能力。第二次是 D3.js 把 SVG 选为原生载体，让它成了 Web 数据可视化的默认底层。第三次是设计工具生态全面倒向 SVG，让它成了设计资产的「通用无损交换格式」。第四次是大模型时代，它作为「文本化的图形描述」突然变得极度契合。

四次回报，每一次都来自同一个根源：SVG 是文本，不是像素。 这个 1998 年的设计决策，在 25 年后仍然是它最大的护城河。

更有意思的是，如果你把 SVG 今天的每个核心优势和劣势追溯回历史节点，会发现一个规律——很多优势和劣势共享同一个根源。「文本化」带来了长寿、Web 集成、AI 契合（优势），也带来了安全攻击面（劣势）。「保留模式」带来了交互和无障碍（优势），也带来了性能瓶颈（劣势）。「开放标准」带来了跨厂商存活（优势），也带来了演进节奏失控（劣势）。

这是技术演化的一个普遍规律：核心设计决策是中性的，它的「优势」和「劣势」是同一个硬币的两面，你无法只要好的那一面。 SVG 的 25 年，就是把这种两面性活成一部完整历史的样本。

三个未来剧本

基于这些，我对 SVG 未来几年的走向有三个判断。

最可能的剧本：长期悬置，事实标准主导，AI 成为新增长极。 SVG 2 很可能长期停留在 Candidate Recommendation。这不是灾难——HTML5 早期也是在活稿状态下被广泛实现的，事实标准先于规范标准是 Web 的常态。真正的增长极在 AI 侧，StarVector、Recraft 这些工具会持续改进，通用大模型写 SVG 的能力会快速提升。但安全攻击面会同步放大，SSVG（Secure SVG）子规范或类似方案会被严肃讨论。

最危险的剧本：大规模场景被持续蚕食，标准进一步边缘化。 如果数据可视化、地图、复杂 UI 这些 SVG 的传统领地全面迁移到 Canvas/WebGL，SVG 的「应用面」会萎缩成「图标 + 简单图表 + 设计资产」的小众领域。最坏的结果是 SVG 沦为「invisible infrastructure」——像 ASCII 或 UTF-8 那样，重要但无人讨论。

最乐观的剧本：SVG 在 AI Agent 时代成为「可编程图形」的标准载体。 如果 AI Agent 真的成为主流的工作方式，那么「可被 agent 读取、修改、生成的图形格式」会变得极度重要。位图对 Agent 是不透明的，但 SVG 对 Agent 是透明的——每个元素有 ID、有结构、有语义。在这个剧本里，SVG 不只是图片格式，而是「agent 和人类共享的图形语言」。

这个剧本是可能的，因为它的前置条件（Agent 化）正在发生。而且它延续了 SVG 25 年的主线——每一次技术浪潮，都会重新发现 SVG 作为「文本化、结构化、Web 原生」载体的价值。 inline SVG 是 Web 2.0 时代的发现，D3 是数据可视化时代的发现，StarVector 是 AI 时代的发现。Agent 时代会不会是第四次？我觉得有可能。

写在最后

回到开头那个故事：2005 年的 SVG，今天还能渲染。

现在回头看，这件事的意义比「一个老文件能打开」要深得多。它说明的是：一个基于开放文本标准的设计，有一种独特的抗时间能力。 闭源插件会死，厂商私货会被淘汰，商业产品的格式会随版本失效，但一个由 W3C 治理、用 XML 文本描述、不依赖任何单一实现的开放标准，可以穿越所有这些技术浪潮。

SVG 的 25 年，是开放标准哲学的一份长期实验报告。实验的结论，在今天这个 AI 重塑一切、封闭生态重新抬头、技术周期越来越短的时代，格外值得记住——

有些东西，因为愿意放弃控制，反而活得更久。

核心来源：W3C SVG 工作组《Secret Origin of SVG》、SVG 2 规范、2024 工作组章程；CSS-Tricks 《Icon Fonts vs SVG》；Smashing Magazine 《SMIL is Not Dead》；StarVector 论文 arXiv:2312.11556；Simon Willison 鹈鹕骑自行车 benchmark；Hacker News 《An SVG is all you need》、《SVG Clickjacking》；Igalia LBSE 项目；Library of Congress SVG 格式档案。