coords坐标失效是规范行为而非bug，因其仅基于图片原始尺寸（naturalWidth/Height）映射，不响应CSS缩放、max-width或DPR变化；修复需区分静态/动态场景，并优先采用SVG方案。
coords 坐标失效不是 bug，是规范行为——它只认图片原始尺寸，不随 CSS 缩放、max-width 或视口变化自动适配。硬写像素值在响应式页面里必然漂移，修复必须明确区分“静态场景”和“动态场景”。
coords 失效的三个典型现象
热区点不中、高亮框飘到图外、区域缩成一条线或完全消失——这些都不是随机故障，而是坐标系断裂的明确信号：
- 用 Chrome 开发者工具悬停
area元素，Computed面板里coords显示为NaN或空字符串 → 说明字符串解析失败（常见于逗号后多空格、奇数个数值、混入单位如px） - 图片用了
width: 100%或max-width: 100%，但coords还按设计稿尺寸填 → 浏览器仍以img.naturalWidth为基准映射，导致坐标“放大”覆盖错误区域 - 在 Retina 屏（
window.devicePixelRatio === 2）下点击失准 → 设计稿是 @2x 导出的，你直接抄了标注里的像素值，没除以 dpr
shape="poly" 多边形 coords 必须严格偶数且顺序正确
多边形不是“一堆点”，而是按顺序连接的顶点序列；浏览器逐对读取，错一位整个形状就翻转：
-
coords字符串必须是偶数个纯整数，例如"120,80,135,60,150,80,140,110"→ 解析为 (120,80)→(135,60)→(150,80)→(140,110)，再自动闭合回 (120,80) - 首尾点不能重复，写成
"120,80,135,60,150,80,140,110,120,80"会让第 5 对覆盖前 4 对，区域异常 - 描点必须基于
img.naturalWidth/img.naturalHeight，不能在缩放后的页面上截图取值；否则坐标系错位，JS 重算也救不回来 - 用 Inkscape 或 MapEdit 导出 SVG 后提取路径点，比手敲可靠得多；人体结构、中国省份这类凹多边形，30–50 个点足够兼顾精度与可维护性
必须用 map/area 时，JS 动态重算的硬性条件
别在 DOMContentLoaded 里直接执行重算逻辑——img.naturalWidth 可能还是 0；缩放比计算也必须分 X 和 Y 独立处理：
立即学习“前端免费学习笔记（深入）”；
- 监听
img.onload和ResizeObserver（比window.onresize更稳），确保图片已 layout 完成再读offsetWidth/offsetHeight - 缩放比必须分开计算：
scaleX = img.offsetWidth / img.naturalWidth，scaleY = img.offsetHeight / img.naturalHeight；矩形和圆形的半径也要缩放，不能只动坐标 - 解析
coords时用.split(',').map(Number)，再按索引奇偶分别乘scaleX/scaleY，最后Math.round()取整 → 少这一步，小数坐标会被浏览器静默丢弃 - 避免在
area上直接写style="display:none"或用visibility: hidden控制显隐 —— 这会导致offsetWidth读不到真实值，缩放比崩坏
真正省心的替代方案：用 SVG 替代 map/area
SVG 不是“高级选项”，而是解决 coords 失效问题的现代标准解法——它把响应式逻辑从 JS 搬进了声明式属性里：
-
<svg viewBox="0 0 1200 800">中的viewBox定义原始坐标系，容器宽高由 CSS 控制，所有子元素（<rect>、<circle>、<polygon>）自动缩放 - 热区坐标直接写百分比：
<rect x="10%" y="20%" width="20%" height="15%">，无需 JS 计算，也不受 DPR 影响 - 点击事件绑定在
<svg>上，用event.target区分区域，支持事件委托，适合全国 342 个县级区划这种密集热区 - 导出地图时，优先选 SVG 格式；已有 PNG，可用在线工具（如 svgomg）转为矢量路径，再手动补
href和aria-label
最常被忽略的是：哪怕你决定用 JS 重算 coords，也得先确认 img 的 width/height 属性是否设置，以及外层容器有没有 padding 或 border 干扰 offsetWidth 读值——这些细节不校验，重算结果全是错的。
