谷歌把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的依賴安裝？