用 transform: translatey(-4px) 配合双层 box-shadow（近距偏暗、远距柔和）实现自然抬起效果，需加 transition 且仅过渡这两个属性，注意 z-index 和 stacking context 问题，并用 @media (hover: hover) 兼容移动端。
hover 动画用 transform + box-shadow 实现抬起效果
直接用 transform: translateY(-4px) 配合加深的 box-shadow 就能做出自然的“悬浮抬起”感，不需要改布局或触发重排。
关键不是动得高，而是阴影变化要匹配位移——人眼对阴影深浅比对位置更敏感。抬起 4px 时，如果阴影还是平铺的浅灰，看起来就像卡片飘在半空没落地；加一层偏暗、略扩散的阴影，才像被光从上方照出的立体投影。
-
transform必须用translateY，别用margin-top或top：前者触发 GPU 加速且不触发重排，后者会让浏览器反复计算布局，滚动或动画卡顿明显 -
box-shadow建议写两层：一层近距偏暗（如0 2px 6px rgba(0,0,0,0.15)），一层远距柔和（如0 8px 24px rgba(0,0,0,0.08)），hover 时同时增强两层的模糊半径和透明度 - 必须加
transition，且只过渡transform和box-shadow：写all 0.2s容易误触其他属性（比如意外过渡opacity导致文字发虚）
阴影层次错乱？检查 z-index 和 stacking context
卡片 hover 抬起后被后面元素遮挡，或者阴影被父容器裁切，基本都是 stacking context 搞的鬼，不是阴影参数问题。
常见陷阱是给卡片加了 position: relative 但没设 z-index，结果 hover 后虽然位移了，渲染层级却没变；或者父容器有 overflow: hidden 或 transform，悄悄创建了新 stacking context，把阴影截断在内部。
立即学习“前端免费学习笔记（深入）”；
- 抬起的卡片至少设
z-index: 10（数值不重要，关键是比兄弟元素高） - 检查父级是否带
transform、opacity 、<code>filter或will-change：这些都会创建局部 stacking context，导致子元素的z-index只在该容器内生效 - 阴影被裁切？优先删掉父容器的
overflow: hidden；不能删就用clip-path: none覆盖，或把阴影改用伪元素::after绘制并脱离父容器流
移动端 hover 不触发？别依赖 :hover
手机上没有悬停概念，:hover 在 iOS Safari 和部分安卓浏览器里要么不触发，要么只在点击后短暂生效，靠它做抬起动画等于白写。
真要兼容触摸设备，得用 :active + JavaScript 监听 touchstart/touchend 切换 class，或者直接用 @media (hover: hover) 做媒体查询隔离。
- 最简方案：用
@media (hover: hover) and (pointer: fine)包裹 hover 规则，确保只在有精准指针（鼠标/触控笔）且支持 hover 的设备上生效 - 如果必须全端一致，放弃 hover，改用
.card.is-liftedclass 控制状态，JS 在touchstart时添加，touchend时移除（注意防 touchcancel） - 别用
ontouchstart写内联事件——移动端 click 有 300ms 延迟，touchstart才是即时响应的关键
动画卡顿或闪烁？强制开启 GPU 加速但别滥用
抬起动画一卡，八成是浏览器没走 GPU 渲染管线。加 transform: translateZ(0) 或 will-change: transform 能强制提升图层，但加错地方反而更卡。
will-change 是提示，不是开关；浏览器看到它会提前分配纹理内存，但如果元素根本不动，或频繁切换，就会引发内存抖动甚至掉帧。
- 只对真正参与动画的元素加
will-change: transform, box-shadow，且最好在 hover 前一刻（比如mouseenter时）动态加，hover 结束后立刻移除 - 避免在大量卡片上批量加
will-change：列表滚动时每个 item 都提示“我马上要动”，GPU 内存瞬间吃紧 - 如果用了
transform: translateY()，translateZ(0)已经隐式开启 GPU 加速，不用额外加——多加反而干扰浏览器优化判断
