transition 作用于 width/height 会导致点击区域不同步，应优先使用 transform 和 opacity 组合；避免混用 top/left 与 transform；合理使用 will-change 提升性能，并注意移动端 touchstart 时机问题。
transition 作用在 width/height 上会缩放点击区域
元素尺寸变化时触发 transition，浏览器会按帧插值渲染宽高，但点击热区（hit area）不会实时跟随缩放——尤其在动画中途，视觉上看到按钮变小了，实际仍能点中原始尺寸范围，或反过来点不中已变大的区域。这不是 bug，而是 CSS 渲染与事件坐标系统不同步的自然结果。
- 只对
transform: scale()做过渡更安全：它不影响文档流和布局盒，点击区域随视觉同步缩放 - 避免对
width、height、padding、margin等影响盒模型的属性加transition - 若必须改变尺寸，用
transform: scaleX() scaleY()替代，并确保父容器有overflow: hidden防止内容溢出干扰点击
opacity + transform 组合过渡是点击区域友好的黄金搭配
多数交互反馈（如悬停放大、淡入弹出）不需要真实改变元素占位，用 opacity 控制显隐、transform 控制位移/缩放，既能达成视觉效果，又能保证点击区域始终准确映射到当前视觉位置。
-
opacity过渡不影响布局，也不会导致点击穿透或错位 -
transform是合成层属性，浏览器通常将其提升为独立图层，事件坐标自动跟随变换矩阵 - 不要混用
top/left和transform：前者触发布局重排，后者走 GPU 合成，两者同时过渡会导致行为不可预测
button {
transition: opacity 0.2s ease, transform 0.2s ease;
}
button:hover {
opacity: 0.9;
transform: scale(1.05);
}
用 will-change 提前提示浏览器哪些属性会动
当元素频繁做 transform 或 opacity 过渡时，浏览器可能来不及优化图层分配，导致点击延迟或区域偏移。加 will-change 能让渲染引擎提前准备合成层。
- 只对真正会动的元素设
will-change: transform, opacity，滥用会增加内存开销 - 不要写
will-change: width或will-change: left：这些属性无法被硬件加速，反而拖慢性能 - 动画结束后建议用 JS 移除
will-change，避免长期占用图层资源
移动端 touchstart 时机比 click 更敏感，需额外防误触
在 iOS Safari 或 Android Chrome 中，click 有约 300ms 延迟，而 touchstart 立即触发——如果过渡刚启动，元素还没完成位移，touchstart 坐标就可能落在旧位置，造成“点了没反应”或“点到隔壁元素”。
立即学习“前端免费学习笔记（深入）”；
- 给过渡中的元素加
pointer-events: none，动画结束再恢复，可彻底规避误触 - 或监听
transitionend事件，在回调里重新启用交互 - 避免在
:active状态下同时触发过渡：移动端 touch 事件流复杂，容易打断状态判断
真正难处理的不是怎么写过渡，而是过渡过程中坐标系是否还跟得上你的视觉预期。很多点击失效问题，查半天 DOM，最后发现只是 height 在动，而浏览器根本没打算让 hit area 跟着它动。