应使用 transform + mousemove 实现图片跟随，因其性能优、无重排、定位准；需配合 requestAnimationFrame 节流、绝对定位、clientX/Y 坐标、移动端 touchmove 兼容及滚动补偿等细节。
直接用 transform + mousemove 实现，别碰 background-position 或 left/top ——前者掉帧严重，后者在滚动或缩放时坐标错位，实测 CPU 占用高到三倍以上。
为什么 background-position 会卡顿、偏移失准
浏览器对 background-position 的更新必须触发 layout → paint 流程，尤其在页面有滚动、缩放或高 DPI 屏幕下，e.pageX/e.pageY 含滚动偏移，而 background-position 又不自动适配容器尺寸变化。结果就是：鼠标一滚图片飞出视口，小屏猛甩、大屏不动，DevTools Performance 面板里 layout 时间暴涨。
改用 transform: translate3d() 后，渲染走合成层（compositor），不重排不重绘，60fps 稳定。你只需要：
- 给图片容器加
will-change: transform（仅需在 hover 或 mouseenter 时动态加，不用全局写） - 确保容器有明确宽高（响应式下用
aspect-ratio或padding-top技巧保比例） - 背景图用
background-size: cover，避免拉伸变形
如何正确归一化鼠标坐标并适配响应式容器
不能直接用 e.clientX 做偏移值——它依赖视口左上角，而响应式容器尺寸随时变。必须把鼠标位置转成“相对于容器内部的归一化比例”（-0.5 ~ +0.5），再乘灵敏度系数。
立即学习“前端免费学习笔记（深入）”；
关键三步：
- 监听容器的
mousemove，不是document（否则移动端失效、滚动时错位） - 用
container.getBoundingClientRect()拿当前容器位置和尺寸 - 计算：
(e.clientX - rect.left) / rect.width - 0.5得 X 归一值，同理算 Y
示例片段：
const rect = container.getBoundingClientRect();
const xNorm = (e.clientX - rect.left) / rect.width - 0.5;
const yNorm = (e.clientY - rect.top) / rect.height - 0.5;
img.style.transform = `translate3d(${xNorm * 20}px, ${yNorm * 20}px, 0)`;移动端 touchmove 怎么不白忙一场
iOS Safari 完全不触发 mousemove，Android Chrome 对触摸也无响应。只写 PC 端逻辑，上线即失效。
必须双监听，并处理三个硬约束：
- 同时绑定
touchstart和touchmove，取e.touches[0].clientX（changedTouches在手指刚落时为空） - 在
touchmove回调里加e.preventDefault()，否则默认滚动行为会吞掉事件 - 给容器加
touch-action: none，禁用系统手势干扰（双指缩放、滑动等）
别忘了加防重复：用 requestAnimationFrame 节流，且只在 touchmove 里存坐标，raf 回调里统一更新 transform。
响应式下容易被忽略的坑
媒体查询改了容器宽高，但 getBoundingClientRect() 返回的是实时值，所以归一化本身是安全的——真正危险的是图片尺寸没跟上。
常见翻车点：
-
img标签用width: 100%但父容器没设max-width，导致超大屏下图片模糊或拉伸 - 伪元素承载背景图时，
::before没设content: ""和position: absolute，偏移无效 - 用
object-fit: cover的<img>在 Safari 下需加-webkit-transform: translateZ(0)触发硬件加速
最隐蔽的问题：滚动时容器位置变了，但 getBoundingClientRect() 每次都重算，所以只要你不缓存 rect，就不存在“滚动后偏移悬停”的 bug——但很多人手动缓存了 rect 却忘了在 scroll 或 resize 里刷新它。
