image-rendering仅对<img>的width/height缩放和<canvas>的JS绘制生效，对background-image、transform: scale()及高DPR自动选图无效；crisp-edges是放大缩小均禁用插值的可靠选择，pixelated仅放大有效且缩小必糊。
image-rendering 能控制缩放时的插值算法，但只对 <img> 的 width/height 缩放和 <canvas> 的绘制生效；写在 background-image 或 transform: scale() 上基本无效。
什么时候 image-rendering 才真正起作用
它只在浏览器对位图做「直接像素重采样」时介入，不是加了就起效。关键前提是：图片必须被缩放，且缩放行为发生在 CSS 渲染层。
-
<img src="icon.png" width="32" height="32">—— 原图是 64×64，强制缩到 32×32 → ✅ 生效 -
<img src="icon.png" style="width: 32px; height: 32px">—— 同上，也 ✅ -
background: url(icon.png); background-size: 32px 32px;—— ❌ 大部分浏览器无视image-rendering，Chrome/Edge 需额外加-webkit-optimize-contrast才可能响应 -
transform: scale(0.5)—— ❌ 插值发生在合成层，CSS 层已无权干预 - 用了
srcset且浏览器加载了匹配 DPR 的 @2x 图（如 iPhone 加载了 128×128 图显示在 64×64 容器里）→ 实际未缩放 → ❌ 属性被跳过
crisp-edges 和 pixelated 到底怎么选
别被名字误导：pixelated 语义准确但限制多；crisp-edges 是当前最稳妥、兼容性最好的选择。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
pixelated规范明确定义“仅用于放大”，缩小场景下所有浏览器都会回退到auto→ 缩小必糊 -
crisp-edges在 Chrome 122+、Firefox、Edge 中行为一致，放大/缩小都禁用插值，效果接近最近邻算法 - Safari 至今不支持
pixelated，但支持crisp-edges（并兼容-webkit-optimize-contrast） - 对像素图、图标、文字截图等低分辨率素材，优先写
image-rendering: crisp-edges - 照片、渐变图等自然图像，强行设
crisp-edges可能导致色阶断裂，保持auto更合适
<canvas> 里画像素图，image-rendering 为啥没反应
因为 image-rendering 是 CSS 渲染层控制项，而 <canvas> 的绘制逻辑在 JS 上下文里，两者不在同一控制域。
立即学习“前端免费学习笔记（深入）”；
- ❌ 错误做法：
<canvas width="32" height="32">，再用 CSS 拉伸到 128×128，指望image-rendering救场 → 必糊 - ✅ 正确做法：保持
canvas.width/canvas.height为原始尺寸（如 32×32），然后 JS 中设ctx.imageSmoothingEnabled = false - ✅ 动态缩放时：用
ctx.scale(4, 4)+ctx.drawImage(img, 0, 0)，而不是拉伸<canvas>元素本身 - 给
<canvas>元素加image-rendering: pixelated是有效的，但必须配合ctx.imageSmoothingEnabled = false才稳；单独用任一方式，在高 DPR 屏或旧版 Chrome 上可能失效
很多模糊问题根本不在 image-rendering 配置本身，而是 srcset 没配对、transform 绕过了渲染层、或 <canvas> 尺寸设置错误——先确认是否真在缩放，再调这个属性。
