shape属性决定coords解析规则，浏览器严格按shape值拆解coords数字：rect需4个、circle需3个、poly至少6个；coords以原图尺寸为基准，与css缩放无关；area必须嵌套在name匹配的map中且usemap带#前缀。
shape属性决定coords怎么解析
浏览器根本不关心你写的是“矩形”还是“圆”，它只认shape的值，然后按固定规则拆解coords里的数字。写错shape，coords就全白配——比如shape="rect"却给了6个数字，浏览器会硬截前4个，后2个丢掉；shape="circle"只收3个数，多一个就忽略。
常见错误现象：shape="oval"或shape="rounded"在所有浏览器里都降级为rect，控制台不报错，热区却偏得离谱；shape="polygon"拼写成shape="polygone"，直接当default处理，覆盖整张图。
-
shape="rect"→ 严格要求coords含且仅含4个数字：x1,y1,x2,y2 -
shape="circle"→ 严格要求3个数字：cx,cy,r，半径不能为负或0 -
shape="poly"→ 至少6个数字（即3组x,y），奇数个会被截断 - 大小写敏感：
CIRCLE、Rect无效，必须小写
coords数值永远以原始图片尺寸为基准
哪怕你用CSS把<img>缩到200×150显示，只要原图是1600×1200，coords就必须按1600×1200来算。否则热点会严重偏移——比如coords="0,0,1600,1200"本该覆盖全图，但缩放后实际只命中左上角一小块。
调试时最容易忽略这点：开发者工具里看到的渲染尺寸 ≠ coords参考系。浏览器压根不读CSS宽高，只认<img>的naturalWidth/naturalHeight。
- 稳做法：用JS读
img.naturalWidth和img.naturalHeight，再按缩放比反推coords - 懒做法：给
<img>加width和height属性（不是CSS），强制渲染尺寸与原始一致 - 别信“自动适配”：没有浏览器会帮你换算
coords，写了就是写了
poly区域首尾不闭合？浏览器自动补，但别依赖
shape="poly"的coords不需要重复首点，浏览器会自动连接末点回起点形成封闭区域。但这只是规范行为，不是渲染保障——如果坐标点太少（如只有2组x,y）、或相邻点间距小于8px，移动端点击极易失效。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
真实问题常出在描点环节：手绘多边形时导出坐标顺序错乱，或导出工具多加了逗号导致解析中断（例如coords="10,20,30,40,,50,60"中间两个逗号，第二组coords就废了）。
- 至少提供3组坐标，否则不构成有效多边形
- 用逗号分隔，禁用中文逗号、空格混用
- 移动端热区建议最小包围矩形宽高≥44px，避免误触
- 调试技巧：临时给
<img>加border: 1px solid red，对照开发者工具量真实像素
area必须嵌在map里，且usemap必须精确匹配
<area>标签本身不渲染、不生效，离开<map></map>就是一段死HTML。而usemap属性值必须带#前缀，且与<map name="xxx"></map>中的name完全一致（包括大小写、空格、符号）。
典型失效场景：usemap="#roomMap"对应<map name="roommap"></map>（小写m）、usemap="roomMap"（漏#）、<map id="roomMap"></map>（用了id而非name）——全部静默失败，无控制台提示，热区就是点不动。
-
<map></map>必须有name属性，不能只靠id -
usemap值必须是"#xxx"格式，不能是"xxx"或"#xxx "（尾部空格） - 多个
<area>按书写顺序覆盖，先写的优先响应，重叠时后写的被遮住
最麻烦的其实是坐标换算和命名匹配这两个环节：一个错位，一个断连，问题现象完全一样——“点不中”。但根源完全不同，查的时候得分开盯。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
