谷歌把80行代码藏了10年，开发者扒出后集体真敢用

html2canvas下载量2.3亿次，dom-to-image周活百万级，modern-screenshot被3.8万个项目依赖——这些库干的是同一件事：把网页变成图片。但它们的底层技术简单到离谱，简单到你根本不需要库。

一位前端开发者用原生浏览器API复刻了完整功能，代码只有80行。没有DOM克隆，没有递归遍历计算样式，四步搞定：SVG foreignObject嵌入HTML→编码成数据URI→Image对象加载→Canvas导出PNG。浏览器自己的渲染引擎包办一切，你只是在借它的力。

第一步：foreignObject，SVG里的"特洛伊木马"

SVG规范里有个冷门元素叫，1999年就写进标准，2011年所有主流浏览器支持完毕。它的作用是在SVG内部打开一个"窗口"，塞进去完整的HTML文档——div、CSS、甚至Web字体，浏览器照样渲染。

代码结构长这样：外层SVG定宽高，foreignObject占满100%，里面套一个带XHTML命名空间的html标签。body的样式需要手动重置，margin归零、box-sizing统一，否则各浏览器默认表现参差不齐。

关键细节在charset。必须声明utf-8，否则emoji和中文会成乱码。作者最初踩过坑：漏写meta标签，测试时英文正常，一上中文直接崩。

第二步：encodeURIComponent，为什么不用base64

SVG字符串要变成能加载的URL。第一反应是btoa()转base64，代码更短、看着更"专业"。但btoa()有个致命缺陷：遇到非拉丁字符直接抛异常。

测试用例很简单：在HTML里放个或"中文"。btoa()报"The string to be encoded contains characters outside of the Latin1 range"，encodeURIComponent则通吃所有Unicode。最终URL前缀是"data:image/svg+xml;charset=utf-8,"，不是常见的"data:image/svg+xml;base64,"。

这个选择影响了后续所有兼容性。base64编码后体积膨胀33%，encodeURIComponent对中文反而更省空间——一个汉字utf-8占3字节，encode后变成6个字符（如%E4%B8%AD），但base64固定把3字节扩成4字节。

第三步：Image.onload，浏览器替你打工

new Image()设置src为那个data URI，浏览器开始干活：解析SVG→遇到foreignObject→启动HTML渲染管线→布局、绘制、合成，全流程走一遍。onload触发时，一张位图已经躺在内存里。

这里藏着个认知陷阱：很多人以为html2canvas在"模拟"浏览器渲染，实际上它早期版本确实这么干——遍历DOM、计算computed style、用canvas API手动画边框和文字。结果就是CSS支持残缺，flexbox和grid长期不支持，阴影模糊效果全靠近似算法。

foreignObject方案的本质是偷懒：既然浏览器能渲染HTML，何必重写一遍？代价是SVG的sandbox规则： foreignObject里的内容受同源策略约束，外部图片需要CORS头，内联script不会执行，外部CSS文件可能因安全限制被屏蔽。

第四步：Canvas导出，质量与体积的博弈

img.onload里创建canvas，drawImage把SVG渲染结果位图化，toBlob或toDataURL拿到最终文件。控制点有两个：canvas尺寸决定输出分辨率，toBlob的quality参数控制JPEG压缩比。

实测数据：一个800×600的复杂卡片，PNG输出240KB，JPEG quality=0.9压到85KB，quality=0.8进一步到62KB，肉眼几乎看不出损失。但foreignObject有个硬限制——它渲染的是矢量过程的终点，文字已经栅格化，输出PNG后再放大会有锯齿，不像纯SVG能无限缩放。

80行代码的边界在哪？

作者列了三个明确限制：一、外部资源必须允许跨域，img标签的crossOrigin="anonymous"和服务器CORS头缺一不可；二、Web字体需要内联为data URI，否则 foreignObject 可能拿不到；三、CSS特性受浏览器SVG支持度制约，比如backdrop-filter在部分浏览器的外国人对象里失效。

对比专业库：html2canvas 2023年推出的v1.4.1仍用纯JS渲染，但提供了useCORS和allowTaint等补丁；modern-screenshot直接基于foreignObject，代码量和这80行相当，但补全了字体预加载和阴影修复。换句话说，生产环境要不要依赖库，取决于你愿意自己维护多少边缘case。

一个未被官方文档提及的细节：Chrome 109之后，foreignObject内的position:fixed会相对于SVG视口定位，而非视口窗口。这导致部分固定定位元素"错位"，需要手动改写成absolute。该行为变动 buried 在Chromium issue 1382013的讨论串里，没进任何release note。

作者开源的Demo页面被Hacker Daily顶到首页，评论区最高赞是："用了三年html2canvas，今天才知道我在交智商税。"但另一条回复更冷静："你的80行能处理Shadow DOM和CSS变量吗？我赌五美元不能。"

技术选型从来不是代码行数的比较。当截图需求从"偶尔导出分享卡片"变成"服务端批量生成营销素材"，那些边缘case的补丁代码就会从"冗余"变成"救命"。这80行的价值在于揭示了一个被封装遮蔽的事实——浏览器早就给了你最短的通路，走不走得通，取决于你的路有多宽。

如果谷歌在2011年 foreignObject 普及时就官方推过这个方案，前端生态会减少多少MB的依赖安装？