transition-duration 在媒体查询中不生效是因为浏览器未触发重绘，需通过锚点类配合完整 transition 声明（含 property 和 timing-function）并在必要时强制重排；避免使用 all；优先采用 transform/opacity；适配 prefers-reduced-motion。
transition-duration 在媒体查询里写不生效？
直接在 @media 里改 transition-duration 没反应，不是你写错了，是浏览器没触发重绘——它只在属性值真正变化时才重新计算过渡，而媒体查询切换本身不改变元素当前状态。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 给需要响应式过渡的元素加一个「锚点类」，比如
js-transition-target，然后在不同断点下用该类名控制transition整体声明 - 避免只改
transition-duration，要连带指定transition-property和transition-timing-function，否则浏览器可能回退到初始值或忽略变更 - 如果依赖 JS 动态切换断点（比如模拟移动端缩放），记得在 class 切换后强制触发一次重排，例如读取
offsetHeight
示例：
@media (max-width: 768px) {
.js-transition-target {
transition: transform 0.2s ease, opacity 0.15s linear;
}
}
@media (min-width: 769px) {
.js-transition-target {
transition: transform 0.35s cubic-bezier(0.4, 0, 0.2, 1), opacity 0.25s ease;
}
}
transition-property 写 all 会导致意外动画
写 transition: all 0.3s 看似省事，但只要元素任意可动画属性（包括 box-shadow、background-color、甚至 z-index 的隐式层叠变化）被 JS 或 CSS 修改，就会触发过渡——这常导致卡顿或视觉干扰。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 只对明确要动的属性写
transition-property，比如transition-property: transform, opacity - 避免在全局样式（如
* { transition: all ... }）里设过渡，子元素继承后极难排查 - 用
will-change: transform配合明确的transform过渡，能提升渲染效率，但别滥用——它会提前创建图层，增加内存开销
移动端 touch 触发 transition 卡顿或跳变
在 iOS Safari 或部分安卓 WebView 中，:hover 或 JS 监听 touchstart 后立刻修改 transform，常出现首帧延迟或跳过过渡——本质是浏览器把 touch 事件和样式更新放在不同线程，且默认禁用非合成属性的硬件加速。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 确保过渡属性是「可合成」的：只用
transform和opacity，别碰left、top、width这类触发布局重排的属性 - 在目标元素上加
transform: translateZ(0)或will-change: transform，强制启用 GPU 图层（注意：仅在必要时加，不要全局铺） - 避免在
touchstart里直接改样式，改用requestAnimationFrame包一层，让样式变更对齐下一帧渲染
prefers-reduced-motion 用户开启后过渡还跑？
用户在系统设置里开了「减少运动」，但你的 transition 依然执行——这不是 bug，是默认行为。CSS 并不会自动禁用过渡，得你主动适配。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
@media (prefers-reduced-motion: reduce)覆盖所有过渡声明，统一设为transition: none或极短时长（如0.01s） - 别只处理
transition，动画（@keyframes）和scroll-behavior也得一并关掉 - 测试时别只靠 Chrome DevTools 的模拟开关，真机进系统设置开一遍，iOS 和 macOS 的触发逻辑略有差异
容易被忽略的是：第三方 UI 库（比如某些 React 组件）自带的过渡往往没做 prefers-reduced-motion 适配，得手动覆盖它们的 class。
