用 transform 而不是 left/right 是因后者触发重排、卡顿，前者由 GPU 加速、不干扰文档流，且 iOS Safari 兼容性更好；需配合 position: fixed/absolute、translateX/Y/Z、cubic-bezier 优化曲线，并用 transitionend 替代 setTimeout 控制时序。
为什么用 transform 而不是 left 或 right
直接改 left 或 right 会触发浏览器重排（reflow），尤其在频繁更新的通知列表中，容易卡顿；transform 属于合成层属性，由 GPU 加速，动画更顺滑，且不影响文档流。iOS Safari 对 transform 的兼容性和性能也明显优于定位偏移类属性。
常见错误现象：弹窗“啪”一下闪现，或在低端安卓机上掉帧严重——大概率是用了 left: -100% + transition: left 0.4s，但没加 will-change: transform 或未强制开启硬件加速。
- 必须把动画元素设为
position: fixed或absolute，否则transform移动时可能影响布局 - 初始状态用
transform: translateX(100%)（右侧滑入）或translateY(-100%)（顶部滑入），别用display: none控制显隐——它会中断 transition - 移动端建议加
transform: translateZ(0)或will-change: transform触发硬件加速，但后者慎用，长期开启可能增加内存压力
cubic-bezier 曲线怎么选才不生硬
默认的 ease（即 cubic-bezier(0.25, 0.1, 0.25, 1)）适合按钮反馈，但通知弹窗需要更轻快的“弹出感”或更克制的“滑入感”。生硬的动画往往源于曲线两端斜率突变——比如用 cubic-bezier(0.42, 0, 1, 1)，起始太猛，用户还没反应过来就到位了。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 右侧滑入推荐
cubic-bezier(0.34, 1.56, 0.64, 1)：起始略缓、中段提速、末尾柔和回弹，模拟物理惯性 - 顶部下拉推荐
cubic-bezier(0.22, 0.61, 0.36, 1)：比ease-in-out更早开始减速，避免“砸”下来的感觉 - 千万别用
cubic-bezier(0, 0, 0, 0)这类非法值——Chrome 会静默降级为linear，Safari 可能直接跳过动画
JS 控制弹窗显隐时，classList.add() 为什么有时没动画
最常见原因是：添加 show 类后，立刻读取了元素尺寸（如 offsetHeight、getBoundingClientRect()），触发了强制同步布局（forced reflow），导致浏览器跳过 transition，直接渲染终态。
使用场景：你调用 showNotification('新消息') 后，想等动画结束再 focus 输入框，或限制同时只显示 3 条通知。
- 正确做法：用
getComputedStyle(el).transform检查当前状态，或监听transitionend事件，而不是靠setTimeout猜时长 - 注意事件冒泡：
transitionend在子元素上也会触发，需判断e.propertyName === 'transform' - 如果通知要批量进出场，避免连续
add/remove同一个类——先remove再add中间加void el.offsetWidth强制重排（仅当真有必要）
多条通知堆叠时，transform 动画如何避免互相遮挡
纯靠 top 或 margin-top 排列通知，动画过程中会出现“上一条还没走完，下一条已顶上来”的错位。本质是 DOM 顺序和视觉顺序不一致。
解决方案不是改动画，而是重构布局逻辑：
- 所有通知容器统一用
position: fixed+top: 0，每条通知通过transform: translateY(Npx)独立位移，互不干扰 - 用 JS 维护一个队列数组，每次新增通知时，重新计算每条的
translateY偏移量（基于前一条高度 + 间距），再批量触发style.transform - 移除某条通知时，不要直接
removeChild，而是先加removing类触发动画（如transform: translateX(100%)），动画结束后再真正删除 DOM
真正难的不是写对一行 transition，而是让每条通知的进入、停留、退出都保持节奏一致，且不因 JS 执行时机或浏览器重排而失步——这需要把动画控制权交给 CSS，JS 只负责开关和调度。
