窗口缩放时过渡不触发？css本身根本不管 resize
CSS 的 transition 只响应 CSS 属性值的变更（比如 width、opacity 被 js 或伪类修改），而 window.resize 事件不会自动改任何样式属性，所以单纯写 transition: width 0.3s 对窗口缩放完全无效。
真正起作用的是：你得在 resize 回调里主动触发样式变更（比如切换 class、改 style.width），让浏览器感知到“属性变了”，过渡才启动。
常见错误现象：
– 页面写了 transition，但缩放窗口时元素“啪”一下跳变，毫无动画
– 用 matchMedia 监听断点，但没手动加 class 或重设内联样式，过渡照样不跑
- 必须显式修改一个带 transition 的 CSS 属性（如
transform、max-width、opacity） - 推荐用 class 切换而非直接操作
style，更易维护且避免内联样式权重干扰 - 别依赖
resize频繁触发过渡——一次缩放可能触发数十次，容易卡顿或动画撕裂
为什么必须加 JS 防抖？不是加了 transition 就万事大吉
浏览器在拖拽窗口边框时，resize 事件每秒可能触发 50+ 次。如果每次都在回调里切 class 或设 style，相当于每秒强制重排重绘几十次，CPU 升高、动画卡顿、甚至过渡被中断重置。
立即学习“前端免费学习笔记（深入）”；
防抖不是可选项，是必须项。目标不是“等缩放停了再执行”，而是“确保只在缩放稳定后，执行一次样式更新并触发过渡”。
- 用
setTimeout+ 清除机制最稳妥，延迟 150–250ms 足够覆盖人眼感知的“缩放结束” - 别用 Lodash 的
debounce，它默认 leading=false，首次 resize 不触发，可能导致初始断点漏判 - 防抖函数要绑定到具体元素或逻辑块，避免多个 resize 监听器互相覆盖 timeout ID
示例关键片段：
let resizeTimer;<br>window.addEventListener('resize', () => {<br> clearTimeout(resizeTimer);<br> resizeTimer = setTimeout(() => {<br> document.body.classList.toggle('is-large-screen', window.innerWidth > 768);<br> }, 200);<br>});transition 写在哪？class 切换时哪些属性能平滑过渡
过渡声明必须写在「初始状态」和「目标状态」都存在的 CSS 规则里，且两个状态中该属性都需有明确值（不能一个是 auto，一个是 200px）。
容易踩的坑：
– height: auto 无法过渡，得用 max-height 替代
– display: none → block 完全不触发 transition（display 变更会跳过渲染流水线）
– 使用 transform: scale() 比直接改 width/height 更高效，GPU 加速且不影响文档流
- 优先过渡
transform和opacity，性能最好，无重排 - 若需响应尺寸变化，用
max-width/max-height配合足够大的终值（如max-width: 9999px） - 避免对
top/left等定位属性做过渡，除非父容器是position: relative且已脱离文档流
媒体查询 + JS 切换 class，比纯 JS 计算尺寸更可靠
用 window.innerWidth 手动判断断点看似直接，但会漏掉设备像素比变化（如 macos 缩放设置）、iframe 嵌入、浏览器工具栏展开等真实场景。而 matchMedia 是浏览器原生监听，与 CSS 媒体查询完全同步，语义清晰、兼容性好（IE10+）。
实际协作逻辑是：matchMedia 告诉你“现在属于哪个断点”，JS 负责把结果映射为 class，CSS 负责定义这个 class 下所有可过渡的样式。
- 监听
matchMedia('(min-width: 768px)')，比反复读window.innerWidth更轻量 - 在
mql.addListener回调里触发防抖后的 class 切换，而不是在 resize 里重复计算 - 务必在初始化时也执行一次
mql.matches判断，否则页面加载时 class 缺失，过渡无法起始
过渡的起点和终点，永远由 CSS 定义；JS 只是那个准时推门的人。门能不能滑开，取决于门轴（transition 声明）有没有装对，而不是推门力气多大。