为什么 transform: scale() 能缓解高DPI屏幕模糊
本质是绕过浏览器对像素的“插值渲染”：普通缩放（比如 width/height）会让元素在非整数物理像素上绘制，浏览器被迫用双线性插值填充，结果发虚；而 transform: scale() 触发独立图层，GPU 以更高精度做缩放计算，再映射到设备像素网格，保留锐利边缘。
但注意：它只是“缓解”，不是“修复”——最终是否清晰，还取决于原始设计尺寸是否匹配设备像素比（window.devicePixelRatio）。
用 transform: scale() 做 2x 高清适配的实际写法
典型场景：图标、按钮、卡片等固定尺寸 UI 元素，在 Retina 屏下需要视觉大小不变，但用 2x 资源或更精细的渲染。
- 先按 1x 设计稿写样式（比如
width: 100px; height: 40px;），这是逻辑尺寸 - 对容器加
transform: scale(2); transform-origin: 0 0;，让它在高 DPI 下物理渲染为 200×80 物理像素 - 同时用
width和height反向缩小回 100×40 CSS 像素，避免布局撑开：width: 50px; height: 20px; - 必须设
transform-origin: 0 0，否则默认居中缩放会偏移位置
示例：
立即学习“前端免费学习笔记（深入）”；
button.high-dpi {
width: 50px;
height: 20px;
transform: scale(2);
transform-origin: 0 0;
}
容易踩的坑：缩放后点击区域、文字、边框全乱了
transform: scale() 只影响渲染，不改变文档流和事件坐标系。缩放后的元素，其 getBoundingClientRect() 返回的仍是缩放前的逻辑尺寸，但鼠标事件的 clientX/clientY 是缩放后的物理坐标 —— 这会导致：
- 点击热区错位（尤其
scale > 1时，实际可点区域比看起来小） -
border和box-shadow也被放大，可能糊成一团 - 子元素内文字若未重设
font-size，会被无差别放大，显得粗且不协调 - 与
position: fixed或z-index层叠配合时，可能出现意外裁剪
补救建议：对文字单独设 font-size: 0.5em（配合 scale(2)），border 改用 thin solid 或直接用 box-shadow 模拟细线。
比 transform: scale() 更稳的替代方案
真正想保清晰，优先走媒体查询 + 像素比判断，而不是强行缩放：
- 用
@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi)加载 2x 图片或调整字体 - CSS 中直接写
background-image: url(icon@2x.png); background-size: contain; - 对 SVG 图标，根本不用缩放 —— 它天生矢量，只需确保
viewBox正确、无固定width/height破坏比例 - 现代方案可考虑
image-set()：background-image: image-set("icon.png" 1x, "icon@2x.png" 2x);
硬套 transform: scale() 的代价是调试成本上升，尤其当页面存在滚动、动画、第三方组件时，缩放叠加极易失控。
