coords填左上右下仍点不中，因必须基于img.naturalwidth/height原始尺寸而非css渲染尺寸；@2x标注需除dpr，x1
shape="rect"时coords为什么填了左上右下还是点不中
因为coords不是“你看到的图上量出来的坐标”，而是按img.naturalWidth和img.naturalHeight原始尺寸写的像素值。哪怕你把一张 1600×900 的图用 CSS 缩成 400px 宽，coords="100,50,200,150"依然得按 1600×900 下的位置算——否则热区会缩成原图 1/16 大小，几乎点不中。
-
rect必须满足x1 且 <code>y1 ，填反了（比如<code>"200,150,100,50"）会导致区域消失或倒置 - 设计稿给的是 @2x 标注（如
200,100,400,300），实际要先除以window.devicePixelRatio再填，否则在 iPhone 上热区偏移 - 临时调试：给
<img>加style="max-width:90%"，再用浏览器「截图选区」工具比对原始图上的像素位置
poly coords写错一位就全失效，怎么避免手误
poly 的 coords 是一串逗号分隔的数字，必须成对出现（偶数个），顺序即顶点绘制顺序。浏览器不校验合法性，错一位、多一个逗号、少一个数字，整个区域就静默失效——控制台零报错，只表现为“点不动”。
- 导出坐标时，用 Figma 或 Photoshop 的插件直接输出 clean 数组，别手动抄；复制后用正则
/,\s+/g替换所有空格和换行 - 验证是否偶数个：在 JS 中运行
area.coords.split(',').length % 2 === 0，不通过就立刻检查 - 首尾点不用重复（
poly自动闭合），但若顶点过多（>100 个），Firefox 检测 hover 会明显卡顿，建议拆成多个area - 避免自相交多边形（如“8”字形），Chrome 可能填充异常，IE 直接不渲染
响应式页面里coords无法自动缩放，JS重算的关键逻辑
HTML 原生不支持百分比 coords，max-width: 100% 或 width: 50% 会让热区彻底错位。唯一可靠解法是 JS 动态重算，但要注意缩放比不能只读 offsetWidth / naturalWidth——因为宽高缩放可能不一致（比如 height: auto）。
- 必须分别计算
scaleX = img.offsetWidth / img.naturalWidth和scaleY = img.offsetHeight / img.naturalHeight - 遍历每个
<area>，对coords字符串做split(',').map(Number)，再按索引奇偶分别乘scaleX和scaleY - 监听
img.onload和ResizeObserver（比window.onresize更准），避免首次加载时naturalWidth为 0 - 加
requestAnimationFrame节流，防止滚动时高频重算拖慢主线程
什么时候该放弃area改用SVG
当项目已用 Figma 设计、有多个断点、或热区含曲线/镂空/文字轮廓时，硬啃 coords 就是给自己埋坑。SVG 天然适配缩放、dpr 和响应式，且坐标可直接从设计工具导出。
- 高清屏（dpr > 1）下，
coords需手动除以 dpr，而 SVG<path></path>无此烦恼 - 热区形状复杂（如带圆角的徽章、地图上的省界），
poly坐标点易超 200 个，维护成本陡增 - 团队已有 SVG 工作流（Figma → SVG 导出 → 直接嵌入 HTML），比反复调
coords快得多 -
<map></map>在 Shadow DOM 或<picture></picture>内部时默认失效，SVG 则无此限制
coords 的本质是一组静态像素锚点，它不理解“缩放”“设备像素”“设计系统”，只认原始图尺寸。越想让它适应现代布局，越容易掉进无声失效的陷阱。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
