area 标签在 poly 顶点超 50 个时性能显著下降，Firefox 悬停检测慢、移动端响应迟滞，Chrome 虽稍好但仍依赖 DOM 遍历；SVG path 性能更优，尤其用 M/L/Z 构建折线多边形时，支持缩放适配与硬件加速。
area 标签在 poly 区域多于 50 个顶点时明显卡顿
Firefox 下鼠标悬停检测会变慢，移动端普遍响应迟滞；Chrome 表现尚可，但 poly 坐标解析和 hit-test 仍走 DOM 层级遍历，无法硬件加速。这不是代码写法问题，而是 area 的实现机制决定的：每个 poly 都需实时判断指针是否落在由 coords 字符串描述的多边形内，浏览器不缓存几何判定结果。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用开发者工具模拟移动设备，打开“Rendering”面板勾选“Paint flashing”，快速识别频繁重绘区域
- 若热区来自设计稿导出（如 Figma 插件），优先合并相邻小区域，或用
shape="rect"/shape="circle"替代高顶点多边形 - 避免在
polycoords 中混入空格、换行或小数——部分旧版 Safari 会静默跳过整个area
SVG path 的 hit-test 性能取决于 path 数据复杂度，而非数量
path 元素本身不触发重排，其点击检测由渲染引擎底层优化，尤其当 d 属性不含大量贝塞尔曲线（如 C, S, Q）时，性能远超等效 area。但要注意：一个超长 d 字符串（比如 10k+ 字符的中国各省轮廓）会导致首次解析延迟，且 getPointAtLength() 类 API 在动画中频繁调用会拖慢主线程。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
path实现热区时，优先用M、L、Z构建折线多边形，避免A（椭圆弧）和C（三次贝塞尔） - 导出前用 SVGOMG 压缩
d字符串，移除冗余空格和精度（保留 1 位小数足够） - 若需支持键盘聚焦，给
path加tabindex="0"和focusable="true"，但别忘了配套aria-label
移动端触控尺寸与可访问性差异直接暴露在两种方案里
area 的 coords 是绝对像素值，缩放后热区面积可能跌破 44×44px 最小触控推荐尺寸，iOS Safari 会直接忽略点击；而 path 在 viewBox 下天然按比例缩放，只要原始坐标基于合理分辨率（如 1200×800），输出到 375px 宽屏幕时仍能保持物理尺寸达标。
常见错误现象：
- 桌面端点击正常，真机调试时手指点中却无响应
- 用
outline或stroke可视化热区后，发现 SVG 热区边缘清晰贴合，area却“漂”在图片上方几像素处 - 无障碍测试工具报 “clickable element too small”，但检查 DOM 发现
area的coords数值没错——错在它没随 CSS 缩放而重算
不要指望 JS 修补能抹平性能鸿沟
监听 resize + img.onload 动态重写 area.coords 确实能让坐标对齐，但它解决的是“准不准”的问题，不是“快不快”。每次 resize 都要遍历所有 area、正则拆解 coords、乘缩放比、再拼回字符串——这本身就会在低端安卓机上造成 20–50ms 的 JS 阻塞。
而 SVG 方案只需一次 viewBox 设置，后续所有缩放、缩放、旋转都由 GPU 自动处理，无需 JS 干预。真正需要 JS 的地方，是给 path 绑定事件时做防抖或节流，而不是救火式重算坐标。
最容易被忽略的一点：当你在 CMS 模板里硬塞进几十个 area，并配上 onload 重算脚本时，你其实已经把首屏可交互时间（TTI）交给了最不可控的环节——图片加载时机和 JS 执行顺序。
