area标签在移动端营销页基本不可靠，因ios safari和android chrome对小面积poly热区响应差，且area不渲染、不捕获事件，依赖浏览器图像映射支持。
area 标签在移动端营销页上基本不可靠，直接用会大面积失效——不是写法错，而是浏览器行为和触控物理限制共同导致的。
为什么移动端点击 area 没反应
area 本身不渲染、不捕获事件，它依赖浏览器对图像映射（image map）的底层支持。而 iOS Safari 和 Android Chrome 对小面积 poly 热区响应极差，尤其当热区尺寸
- coords 坐标按原始图片像素计算，但营销页图片几乎都用
max-width: 100%或width: 100vw缩放，导致热区严重偏移 - poly 形状在 Safari 中对坐标格式错误（如奇数个数字、空格、换行）静默跳过，不报错也不高亮
- 部分安卓 WebView（尤其旧版）完全不支持
usemap，area元素存在但无任何交互能力 - 即使热区“生效”，iOS 上 hover 效果缺失，用户无法感知可点击区域，转化率直接受损
usemap 与 map name 必须逐字节匹配（移动端更敏感）
移动端浏览器对字符串匹配更严格，大小写、连字符、#号缺一不可。一旦错配，热区彻底静默，且控制台不报错——这是调试时最耗时间的点。
-
usemap值必须以#开头，例如usemap="#promo-map" -
<map name="promo-map"></map>的name必须和usemap中#后面的字符串**完全一致**，包括大小写、连字符、下划线 - 不要写
id="promo-map"试图兼容，Chrome 只认name，id在此场景无效 - 调试方法：右键图片 → “检查”，复制
usemap值；再选中map元素，复制其name，用编辑器做纯文本比对
替代方案比硬扛 area 更实际
营销页面讲求快速上线、高转化、低维护。area 的精度依赖设计稿像素、缩放逻辑、JS 重算，开发成本远高于收益。
- 用
<svg></svg>替代：<path></path>支持百分比坐标、响应式缩放、CSS hover/focus 样式、无障碍属性（aria-label），且所有现代移动端浏览器支持完好 - 用绝对定位 +
div+pointer-events: auto模拟热区：配合 JS 读取图片naturalWidth和offsetWidth计算缩放比，动态设置left/top/width/height，可控性更强 - 放弃图像映射，改用拼图式切片：把原图拆成多个带
href的<img>或背景图<div>，用 CSS Grid/Flex 布局还原位置，适配简单、调试直观 <li>如果必须保留单张大图，优先用矩形 <code>shape="rect"，避免poly—— 它在 Safari 中坐标容错率最低，一个逗号错位就整块失效 - 监听
window.addEventListener('resize', updateCoords)和img.addEventListener('load', updateCoords) - 在
updateCoords()中获取img.naturalWidth/img.offsetWidth得到横向缩放比，同理算纵向比（因object-fit: contain可能导致非等比缩放） - 遍历所有
area元素，按 shape 类型分别处理：rect拆成四值重算，circle重算圆心+半径，poly遍历每对坐标分别缩放 - 注意：Safari 不支持直接修改
area.coords属性，需用setAttribute('coords', newCoords)触发重绘 - 测试必须覆盖 iOS 16–18、Android Chrome 120–128，不能只在桌面 Chrome 模拟器跑通就上线
真要用 area，必须加 JS 补偿缩放
仅当设计方强要求复用已有 PSD 坐标、且无法改用 SVG 时，才考虑 JS 动态重算 coords。但这不是“加一段代码”就能搞定的事。
真正难的不是写出能跑的代码，而是让同一套 coords 在 iPhone SE（375px 宽）、iPad Pro（1024px 宽）、折叠屏（双屏切换）下都准确定位——area 天然不支持这个，得靠 JS 补丁一层层盖，越补越脆。营销页面生命周期短，不如一开始就选 SVG 或定位 div。
