最轻量方案是canvas.toBlob()转WebP，但需注意Chrome92+/Edge92+/Firefox105+支持编码，Safari不支持；须确保元素已渲染且无跨域图片；服务端用Puppeteer/Playwright更可靠；质量设置需分场景，避免盲目压缩；高分屏下必须处理devicePixelRatio防止模糊。
HTML 元素截图用 canvas.toBlob() 保存为 WebP
直接调用 canvas.toBlob() 是最轻量、兼容性较好的方案，但必须注意浏览器是否真正支持 WebP 编码 —— 不是所有支持 WebP 解码的浏览器都支持编码。
- Chrome 92+、Edge 92+、Firefox 105+ 支持
toBlob()的"image/webp"类型参数；Safari 目前（截至 Safari 17）仍不支持，会回退为 PNG - 截图前需确保目标元素已渲染完成、无跨域图片（否则 canvas 会被污染，
toBlob()报错或输出空白） - 示例：先用
html2canvas渲染 DOM 到 canvas，再调用canvas.toBlob(callback, "image/webp", 0.8)，第三个参数是质量（0–1），低于 0.7 可能明显失真
服务端转换：避免前端兼容问题
如果需要稳定输出 WebP（尤其要支持 Safari 或旧 Chrome），把截图逻辑后移更可靠 —— 前端传 HTML 字符串或截图 base64，后端用 Puppeteer / Playwright 截图并导出 WebP。
- Puppeteer 的
page.screenshot({ type: "webp", quality: 85 })能精确控制格式和压缩，且绕过浏览器编码限制 - 注意：传 HTML 到服务端时需过滤 script 标签和内联事件，防止 XSS；若传 DOM 快照，建议用
element.outerHTML+ 简单样式内联，避免依赖外部 CSS 文件路径 - 性能上，服务端截图比前端 canvas 更耗 CPU，高并发时需加队列或限流
WebP 质量与体积的隐性权衡
很多人以为设个 quality: 0.5 就能大幅减小体积，实际效果取决于内容 —— 文字多、色块少的 HTML 截图，WebP 在低质量下反而可能比 PNG 还大。
htmlppt.skill
下载
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 实测：纯文字表格截图，
quality: 0.6的 WebP 比 PNG 大 12%；但含渐变背景或阴影的截图，同一参数下 WebP 小 40%+ - 建议分场景设置：对图表/海报类截图用
quality: 0.7–0.8；对文档/列表类，先试quality: 0.9，再对比体积，别盲目压低 - 没有 alpha 通道需求时，显式传
{ lossless: false }（Playwright）或避免用alpha: true（Canvas），否则强制启用带透明的 WebP 编码，体积陡增
“截图模糊”不是分辨率问题，而是缩放陷阱
常见现象：截出来的 WebP 图片发虚，放大看边缘锯齿或糊成一片 —— 很少是 DPI 设置错误，多数因 canvas 绘制时没处理设备像素比（window.devicePixelRatio）。
- 正确做法：创建 canvas 时，把宽高乘以
devicePixelRatio，再用 CSS 把 canvas 缩回原始尺寸，否则高分屏下 canvas 内容被浏览器插值拉伸 - 用
html2canvas时，务必传{ scale: window.devicePixelRatio }，否则即使后端转 WebP，源头已经模糊 - 如果用了 Puppeteer，记得开
fullPage: true和omitBackground: false，否则截长页面时底部留白或内容裁切
WebP 的坑不在格式本身，而在「谁来编」和「怎么缩放」—— 浏览器编码能力参差不齐，设备像素比又容易被忽略，这两处一错，后面所有优化都打折扣。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
