area标签不依赖图片格式，只依据img渲染后的像素尺寸和坐标系；无论PNG、JPG、GIF、WebP或SVG（作为img src），只要渲染为相同像素尺寸，coords就按左上角(0,0)以像素为单位生效。
area 标签本身不感知图片格式，它只依赖 img 渲染后的像素尺寸和坐标系。PNG、JPG、GIF、WebP 甚至 SVG（当作为 img 的 src）在 area 热区逻辑中表现一致——只要浏览器能正常解码并渲染出像素画布，coords 就按左上角 (0,0) 原点、以像素为单位生效。
为什么 PNG 和 JPG 在 area 中没区别？
因为 area 不读取图片文件头或元数据，它只响应 img 元素最终呈现的宽高（naturalWidth/naturalHeight）和 CSS 缩放状态。无论源图是带透明通道的 PNG 还是压缩的 JPG，只要 img 显示为 800×600 像素，coords="100,50,200,150" 就永远对应该显示区域内的矩形框。
常见错误现象：设计师给了一张高分屏 PNG（2x），但前端未用 width/height 属性或 image-rendering: -webkit-optimize-contrast 控制缩放，导致实际渲染尺寸翻倍，而 coords 还按原始尺寸写——热区就偏了。
- 始终用
img的naturalWidth和naturalHeight做坐标基准，而非文件标注尺寸 - 若图片通过 CSS 缩放（如
width: 100%; height: auto），area坐标不会自动换算——必须用 JS 监听resize并重算coords - WebP 在 Safari 14+ 才完全支持，旧版 Safari 会 fallback 到
onerror加载替代 JPG，此时需确保两张图的像素尺寸严格一致，否则热区错位
SVG 作为 img src 时 area 能不能用？
能，但仅限 SVG 作为位图渲染时——即 <img src="map.svg">。此时浏览器把它当一张“图片”处理，area 行为与 JPG 完全相同。但要注意：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- SVG 内部的
<a>或onclick事件会被屏蔽，area是唯一可交互层 - 如果 SVG 含响应式
viewBox且无固定width/height，渲染尺寸可能因容器变化，coords必须按最终像素值写，不能抄 SVG 源文件里的逻辑坐标 - 不要尝试把
<svg>内联进 HTML 后再套map——usemap对内联 SVG 无效，这是规范硬性限制
GIF 动画的热区会随帧变化吗？
不会。area 绑定的是整张 GIF 的画布空间，不是某一帧。即使 GIF 有 10 帧、每帧内容不同，热区位置始终固定在初始帧解码出的尺寸上。用户点击时，浏览器只检测鼠标坐标是否落在 coords 描述的区域内，不管当前播放到哪一帧。
容易踩的坑：
- 设计师用 GIF 做“状态切换”，比如未选中/已选中两个状态在不同帧，但热区仍覆盖整个区域——用户可能在“未选中”帧点击，却触发了跳转，造成体验割裂
- GIF 解码延迟可能导致首次渲染时
img.naturalWidth为 0，JS 动态生成area时若未监听load事件，坐标会算错 - 某些老旧 Android WebView 对 GIF 尺寸解析不准，建议加
img.onload = () => { /* 重设 coords */ }安全校验
真正影响 area 可靠性的从来不是图片格式，而是渲染后像素坐标的确定性。哪怕你用 AVIF，只要浏览器把它画成 1200×800 的方块，coords 就得按这个数来——任何想绕过像素基准去适配“矢量语义”的做法，都会掉进兼容性深坑。
