放大不卡顿的关键是分级加载：缩略图用小图，点击后异步加载原图并配合decode()解码，避免直接src赋值大图；DOM结构精简，慎用filter等触发重绘属性，尺寸比过大时需切片或WebGL。
不会拖慢——但前提是别在预览阶段就加载高清原图。多数卡顿不是因为“放大”这个动作本身，而是因为图片资源没做分级加载。
为什么放大时卡顿？img.src 直接指向原图是主因
常见错误是：点击缩略图后，直接把 img.src 换成原始大图 URL（比如 4000×3000 的 JPEG）。浏览器要下载、解码、渲染整张图，尤其在移动端或弱网下，明显卡顿甚至白屏。
- 缩略图用
srcset或单独小图（如thumb_300.jpg） - 放大弹窗里再异步加载原图，且加 loading 状态提示
- 避免用
background-image加载大图——它不支持loading="lazy"，也不易控制加载时机
HTMLImageElement.decode() 能提前解码，但别滥用
这个 API 可以让浏览器在后台完成图片解码，避免放大时主线程卡住。但它会立即触发下载和解码，如果用户根本没点开预览，就是浪费带宽和内存。
- 只在用户触发放大动作后、插入
img元素前调用decode() - 务必包在
try/catch里——Safari 旧版、部分安卓 WebView 不支持，会抛DOMException - 对 WebP/AVIF 等新格式效果更明显；JPEG/PNG 提前解码收益有限
放大查看的 DOM 结构影响渲染性能
用 transform: scale() 放大单张 img 元素最轻量；但若套了多层 div + overflow: hidden + position: absolute，可能触发重排或层合成异常。
立即学习“前端免费学习笔记（深入）”；
- 放大容器设
contain: layout paint，减少样式计算范围 - 避免给图片父元素设
filter、opacity或will-change（除非真需要动画） - 移动端慎用
width: 100vw; height: 100vh全屏图——视口缩放、横竖屏切换时容易布局抖动
真正容易被忽略的是：缩略图和原图的尺寸比。如果缩略图是 200×150，原图却是 8000×6000，即使网络够快，解码和光栅化时间也会线性增长——这时候该切片或用 WebGL 渲染器，而不是硬扛。
