用 position: absolute 叠加 实现图片热区，前提是容器必须设 position: relative；热区需同级嵌套于该容器内，以图片左上角为原点定位，尺寸用固定 px 值，display 设为 block 或 inline-block，并补充 aria-label 和 tabindex 保障可访问性。
用 position: absolute 叠加 <a> 实现图片热区，前提是容器必须 position: relative
图片本身不支持原生热区坐标，只能靠层叠定位模拟。关键不是“怎么放链接”，而是“怎么让链接精准贴合图片上的某块区域”。容器没设 position: relative，所有绝对定位的 <a> 都会相对于最近的定位祖先（可能是 body），坐标完全漂移。
实操建议：
- 给图片外层
<div>加position: relative，图片用width: 100%或固定宽高，确保尺寸可控 -
<a>必须和图片同级，且都在该relative容器内，否则 offset 失效 - 热区坐标以图片左上角为原点：比如右上角按钮，
top: 20px; right: 30px;比top: 20px; left: calc(100% - 30px);更稳，避免因盒模型计算误差偏移
热区尺寸用 width/height 而不是 min-width 或 max-width
热区本质是点击靶心，不是响应式内容。用 min-width 会导致小图下热区过大、误触相邻区域；用 max-width 在大图下又缩成一个点，根本点不中。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 热区在高清屏上变小、点击失效 → 没用
px固定尺寸，用了百分比但没同步缩放图片 - 鼠标悬停提示位置偏移 →
box-sizing是默认content-box，但加了padding后实际占位超出设定宽高 - 热区边缘有空白无法点击 →
<a>默认是行内元素，没设display: block或inline-block
正确写法示例：
a.hotspot { display: block; width: 80px; height: 40px; }
响应式图片下热区错位？别用媒体查询硬调坐标，改用 JS 动态重算
CSS 媒体查询只能按视口或容器宽度切，但热区要贴合的是图片内部逻辑区域（比如人脸、按钮图标），而图片可能被 object-fit: cover 裁剪、或宽高比不固定。纯 CSS 无法知道图片实际渲染出的裁剪后坐标。
使用场景：
- 图片宽高不定（如用户上传头像）
- 需要支持缩放、旋转等交互后热区仍有效
- 多设备适配要求严格（如医疗影像标注）
实操建议：
- 监听
img的load和window.resize，用getBoundingClientRect()获取图片真实渲染位置和尺寸 - 热区原始坐标存为相对比例（如
{ x: 0.35, y: 0.22, w: 0.1, h: 0.06 }），再乘以当前图片宽高得出像素值 - 避免每帧都重算：用
throttle控制更新频率，resize 时延迟 100ms 再执行
无障碍与可访问性容易被忽略：热区必须有明确语义和焦点行为
只加 <a href="#"> 不够。屏幕阅读器看不到“这是头像右耳的编辑按钮”，键盘用户 Tab 进来后，如果没 focus 样式或 tabindex，就等于不存在。
容易踩的坑：
- 用
<div onclick="...">代替<a>→ 缺失原生键盘支持（Enter/Space 触发）、无 href 语义、SEO 不识别 - 热区没文字内容，只靠背景图 → 必须加
aria-label，例如aria-label="编辑右耳区域" - 焦点框被 CSS 重置为
outline: none且未提供替代样式 → 键盘用户完全迷失当前焦点位置
最小合规写法：
<a href="#" class="hotspot" aria-label="放大左下角地图区域" tabindex="0"></a>
热区不是越密越好，坐标精度、响应延迟、可访问链路，三者缺一不可。尤其当图片来自 CMS 或用户上传时，坐标数据和实际渲染几乎必然存在微小偏差，得留出容错余量。
