max-width: 100%仅解决布局缩放，不解决高dpr屏下像素密度适配问题；需配合srcset+sizes指定物理像素资源、canvas手动缩放缓冲区、避免固定px单位等全链路措施。
高分辨率屏（如 Retina、4K）不是“多加载一张高清图”就能糊弄过去的。核心矛盾在于：CSS 布局单位（px）和设备物理像素不匹配，导致图片模糊、Canvas 失真、滚动条细得点不中、文字边缘发虚——这些现象背后是同一套机制在起作用：浏览器渲染时用的是逻辑像素，但显示输出要落在物理像素网格上。
为什么 max-width: 100% 不够用
它只解决溢出和比例问题，不解决像素密度适配。比如一张 400×300 的 img 在 DPR=2 的 iPhone 上，CSS 宽高仍是 400px×300px，但浏览器实际要往 800×600 物理像素区域里塞内容，没提供 @2x 图就会拉伸模糊。
- 仅靠
max-width: 100%+height: auto无法触发浏览器选择更高密度资源 - 如果父容器本身用了固定 px 宽度（如
width: 320px），那图片再自适应也卡死在低分辨率逻辑尺寸里 - 字体、border、阴影等 CSS 绘制元素也会因 DPR 缩放而变细/变虚，这不是图片问题，但常被误判为“图片没适配”
srcset 和 sizes 必须配对使用
单独写 srcset 几乎等于白写。浏览器默认按 100vw 计算目标尺寸，哪怕你只在 300px 宽的卡片里展示一张图，它也可能选中 1200w 的大图下载。
-
sizes是字符串，不是 CSS；必须写成类似"(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"这种格式 - 每个
srcset条目后必须带宽度描述符（480w）或密度描述符（2x），不能混用："icon.png 1x, icon@2x.png 2x"✅，"icon-480.png 480w, icon@2x.png 2x"❌ - 构建工具（如 Vite）不会自动补
@2x后缀，icon@2x.png 404是高频报错，得靠vite-plugin-imagemin或手动配置resolve.alias
Canvas 渲染模糊的真正原因
不是抗锯齿没开，是缓冲区尺寸（canvas.width/canvas.height）和 CSS 显示尺寸（canvas.style.width/canvas.style.height）不一致。浏览器把小缓冲区拉伸到大显示区域，必然糊。
- 错误写法：
canvas.style.width = '300px'; canvas.style.height = '200px';—— 缓冲区还是默认 300×150 - 正确做法：先设缓冲区
canvas.width = Math.floor(300 * window.devicePixelRatio); canvas.height = Math.floor(200 * window.devicePixelRatio);，再设 CSS 尺寸回 300×200 - 绘图前必须调用
ctx.scale(dpr, dpr)，否则所有坐标（如ctx.fillRect(10, 10, 20, 20)）都要手动乘dpr - iOS 旋转屏幕时
window.devicePixelRatio不变，但布局重排，resize和orientationchange都得监听并重设
滚动条和深色模式下的像素陷阱
高分屏下 ::-webkit-scrollbar { width: 8px } 看起来像一根发丝，尤其 Windows 缩放设为 125% 时，实际物理宽度可能只有 6px 左右，点击命中率骤降。
- 避免固定
px，改用rem：font-size: 16px时，width: 0.75rem≈ 12px，缩放时同步变化 -
window.devicePixelRatio只能作轻量信号（比如决定是否启用 Canvas 高清路径），不可替代媒体查询；深色模式适配要用@media (prefers-color-scheme: dark)，不是靠 JS 读dpr - 滚动条 thumb 颜色在深色模式下若没重置，会和背景融成一片，得显式写
background: #666类似规则
高分屏适配最易被忽略的一点：它从来不是单一技术点的问题。你改了 srcset，但 Canvas 没同步缩放；写了 sizes，却忘了服务端 CDN 对 User-Agent 或 DPR 头的干预；用了 rem 布局，但滚动条仍写死 px——这些环节只要断一环，用户看到的就是模糊、错位、点不中。适配是全链路的事，不是加个属性就完事。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
