html编辑器高分屏模糊的核心是所有可渲染元素须同步适配物理像素密度并响应dpr动态变化，需分别处理canvas缓冲区、光标选区、字体图标、坐标交互及资源加载，缺一不可。
直接改 img.src 或只设 canvas.style.width 不会解决 HTML 编辑器在高分屏下的模糊问题——核心是编辑器内所有可渲染元素（canvas、contenteditable 区域的光标/选区、背景图、图标、字体）必须同步适配物理像素密度，且响应 DPR 动态变化。
Canvas 光标与选区渲染必须按 DPR 重设缓冲区尺寸
多数富文本编辑器（如基于 canvas 实现自定义光标或实时预览的）会在高分屏上出现光标虚化、选区边缘毛边。这不是 CSS 问题，而是绘图缓冲区未对齐物理像素。
-
canvas.width和canvas.height必须设为Math.floor(cssWidth * dpr)和Math.floor(cssHeight * dpr)，不能只靠style.width控制显示大小 - 每次调用
ctx.drawImage()前，需确保图像资源本身已是 2x/3x 分辨率；若加载的是 1x 图，再缩放也糊 - 绘制光标矩形时，别写
ctx.fillRect(x, y, 1, lineHeight)—— 要先ctx.scale(dpr, dpr)，再用逻辑坐标；否则 1px 光标在 DPR=2 下只占 1 物理像素，肉眼不可见 - 监听
matchMedia('(resolution)')变更，而非仅靠resize：窗口拖到外接显示器时resize不触发，但 DPR 已变
contenteditable 元素中的文字与光标需绕过浏览器默认插值
原生 contenteditable 在高分屏下常出现文字发虚、光标抖动，尤其当编辑器启用自定义字体或行高计算时。浏览器对文本的亚像素渲染无法用 JS 直接干预，只能约束渲染路径。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 给编辑容器加
style="image-rendering: pixelated; image-rendering: -webkit-optimize-contrast;"，部分缓解光标边缘模糊（对 Chrome/Safari 有效） - 避免用
transform: scale(0.5)模拟缩放——它会放大所有渲染误差；应改用font-size配合line-height的物理像素等比缩放 - 若编辑器支持自定义光标（如 SVG 覆盖层），SVG 内部
<path></path>的stroke-width必须按dpr设置：例如逻辑粗 1px → 实际写stroke-width="1"+style="transform: scale(${dpr})" - 不要依赖
getSelection().getRangeAt(0).getBoundingClientRect()的原始值做光标定位——该 rect 返回的是 CSS 像素，需手动乘dpr后再用于 canvas 绘制
图标与背景图必须脱离 srcset 依赖，走 JS 动态加载
HTML 编辑器工具栏图标、状态指示器、背景网格线等，往往用 background-image 或内联 svg 实现，而它们不支持 srcset。硬编码 @2x 后缀或只准备 2x 资源，在 Windows 125% 缩放（DPR=1.25）或 iPad Pro（DPR=2.8）下必然错配。
- 统一用 JS 加载图标：根据当前
dpr拼 URL，如toolbar-icon.svg?dpr=${Math.round(dpr * 10) / 10}，后端返回对应分辨率 SVG 或 PNG - 若用 CSS
background-image，改用image-set()并提供 fallback：background-image: image-set("icon-1x.png" 1x, "icon-1_5x.png" 1.5x, "icon-2x.png" 2x);，但注意 Firefox 对非整数x描述符支持有限 - 网格背景（如写作格线）建议用
canvas绘制而非 CSSrepeating-linear-gradient——后者在 DPR 非整数时易出现线条错位或虚化 - 所有图标加载后，检查其
naturalWidth是否 ≥ 所需逻辑尺寸 ×dpr，否则降级显示空白并报错
滚动与鼠标交互坐标必须实时反向校准
编辑器常需监听 mousemove、scroll 定位光标或浮动菜单。在高分屏下，clientX/clientY 和 scrollTop 返回值仍是 CSS 像素，但 DOM 尺寸、canvas 渲染、光标位置都已按 DPR 缩放——不做校准就会偏移。
- 获取鼠标位置后立即换算：
const x = event.clientX * dpr;，再传给canvas绘图或坐标计算 - 滚动容器的
scrollTop是 CSS 像素，但 canvas 中绘制的滚动内容区域是物理像素尺寸，需乘dpr后再做 offset 映射 - 若编辑器使用
requestAnimationFrame做平滑滚动，帧间 delta 必须按dpr归一化，否则 DPR=3 时滚动速度看起来是 DPR=1 的三倍 - 不要缓存
dpr值一次了事——Windows 用户切换缩放比例、Mac 用户连接不同显示器都会导致突变；每次关键交互前重新读取
最易被忽略的一点：DPR 不是“越高清越好”。在低性能设备（如旧款 iPad 或低端安卓平板）上强行按 DPR=3 渲染，会导致 canvas 帧率骤降、内存溢出甚至白屏。真实项目中应结合 deviceMemory、hardwareConcurrency 和 DPR 综合分级，而不是无条件放大。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
