coords填左上右下仍点不中，因必须基于img.naturalWidth/Height原始尺寸而非CSS渲染尺寸；@2x标注需除dpr，x1<x2且y1<y2须严格满足，否则区域失效。
shape="rect"时coords为什么填了左上右下还是点不中
因为coords不是“你看到的图上量出来的坐标”，而是按img.naturalWidth和img.naturalHeight原始尺寸写的像素值。哪怕你把一张 1600×900 的图用 CSS 缩成 400px 宽，coords="100,50,200,150"依然得按 1600×900 下的位置算——否则热区会缩成原图 1/16 大小，几乎点不中。
-
rect必须满足x1 < x2且y1 < y2，填反了（比如"200,150,100,50"）会导致区域消失或倒置 - 设计稿给的是 @2x 标注（如
200,100,400,300），实际要先除以window.devicePixelRatio再填，否则在 iPhone 上热区偏移 - 临时调试：给
<img>加style="outline: 1px solid red"，再用浏览器「截图选区」工具比对原始图上的像素位置
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）。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 必须分别计算
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>无此烦恼 - 热区形状复杂（如带圆角的徽章、地图上的省界），
poly坐标点易超 200 个，维护成本陡增 - 团队已有 SVG 工作流（Figma → SVG 导出 → 直接嵌入 HTML），比反复调
coords快得多 -
<map>在 Shadow DOM 或<picture>内部时默认失效，SVG 则无此限制
coords 的本质是一组静态像素锚点，它不理解“缩放”“设备像素”“设计系统”，只认原始图尺寸。越想让它适应现代布局，越容易掉进无声失效的陷阱。
