area coords 坐标系以图片原始像素为基准，浏览器解析时完全忽略 CSS 缩放、视口宽度或 DPR，仅依据 img.naturalWidth 和 img.naturalHeight；shape="poly" 的 coords 必须为整数、无空格、偶数个值；响应式页面中热区必然失准，唯一可靠方案是 JS 动态重算缩放比并更新 coords。
area coords 坐标系以图片原始像素为基准
浏览器解析 coords 时，**完全不看 CSS 缩放、视口宽度或 DPR**，只认 img.naturalWidth 和 img.naturalHeight 这两个原始尺寸。哪怕你用 max-width: 100% 把一张 2400×1600 的图压到 375px 宽，coords="0,0,100,100" 依然按“原始图左上角 100×100 像素区域”映射——实际在屏幕上可能只剩 15×10px，远低于触控最小推荐尺寸。
常见错误现象：
- 桌面调好 coords，移动端点不中
- Chrome 里正常，Safari 点击失效（尤其 poly 区域静默跳过）
- 开发者工具量出的坐标填进去，热区偏移一大截
原因基本都是：量坐标时图片已被 CSS 拉伸，或导出坐标用了设计稿百分比/小数/带空格格式。
shape="poly" 的 coords 必须是整数、无空格、偶数个值
poly 不是“画个形状就完事”，它对输入极其敏感。浏览器按顺序两两取值作为顶点："x1,y1,x2,y2,x3,y3" → (x1,y1)→(x2,y2)→(x3,y3)，但总数必须是偶数；若写成 "100,200,150,180,180,220,130,240"（8 个数），才能构成四边形；少一个就截断，多一个直接错位。
立即学习“前端免费学习笔记（深入）”；
容易踩的坑：
- 从 Sketch/Figma 导出坐标带小数（如
"100.5,200.3"）→ 浏览器丢弃小数后截断，变成"100,200" - 复制坐标时保留了换行或空格（
"100, 200, 150, 180"）→ 多数浏览器只取第一个逗号前的"100"，后续全失效 - 顶点顺序错乱（比如顺时针 vs 逆时针）→ 多边形视觉正常，但某些浏览器 hit-test 判定失败
响应式页面中 area 热区必然失准，没有纯 HTML/CSS 解法
这是原生限制，不是 bug。HTML 规范明确要求 coords 是像素绝对值，且不随渲染尺寸变化。所以只要图片用了 width/height CSS、object-fit、或在 Retina 屏上显示，coords 就立刻失效。
唯一可靠方案是 JS 动态重算：
- 监听
img.addEventListener('load', updateCoords)和window.addEventListener('resize', updateCoords) -
updateCoords()中计算缩放比：scale = img.offsetWidth / img.naturalWidth - 遍历所有
<area>，把每个coords字符串拆开、转数字、乘scale、再 join 回字符串并赋值
注意：不能只靠 img.width/img.height 属性，它们反映的是 HTML 属性值，不是实际渲染宽高。
usemap 与 map name 必须严格匹配且区分大小写
<img usemap="#worldmap"> 对应的 <map name="worldmap">，name 值必须完全一致，包括大小写和有无空格。浏览器不会自动 trim 或toLowerCase。
典型问题：
-
usemap="#WorldMap"+<map name="worldmap">→ 失效 -
usemap="#map1 "（末尾空格）→ 找不到 map - 多个
<map>用相同 name → 只有第一个生效，其余被忽略
调试时直接在控制台查 document.querySelector('map[name="worldmap"]') 是否返回元素，比猜更准。
最易被忽略的一点：area 标签本身不渲染、不捕获事件，它只是坐标数据容器。真正触发跳转的是 img 元素上由浏览器内部实现的 hit-test 逻辑——这意味着你无法用 addEventListener('click') 直接绑定到 <area> 上做拦截，想干预行为必须代理到 <img> 并手动计算点击是否落在某个 coords 范围内。
