自然过渡效果需只用transform和opacity，因其走GPU合成层不触发重排；禁用width/height/top/left/margin等属性；避免transition:all，应显式声明属性；timing-function推荐ease-in-out，duration宜选0.2s–0.3s。
自然的过渡效果不是靠堆参数，而是靠精准控制哪些属性动、怎么动、什么时候动。核心就一条：只过渡 transform 和 opacity，其他一律避开。
为什么只动 transform 和 opacity 才自然
这两个属性走 GPU 合成层，不触发重排（reflow），帧率稳、不卡顿。而 width、height、top、left、margin 一动就会强制浏览器重新计算布局，尤其在低端设备或复杂 DOM 下，肉眼可见“顿一下”甚至掉帧。
-
transform: scale(1.05)比直接改font-size安全十倍 -
opacity: 0 → 1可以淡入，但visibility: hidden → visible不会过渡——它没过渡行为 - 哪怕只是想“移入”，也用
transform: translateX(10px)，别碰left
transition 写 all 是最常见踩坑点
transition: all 0.3s ease 看似省事，实则埋雷：它会把所有可变属性都拉进来，比如 box-shadow、border-color、甚至意外激活的 outline。鼠标一划过，按钮可能先“闪一下阴影”，再缩放，最后才变色——完全失控。
- 正确写法是显式列出：
transition: background-color 0.25s ease-in-out, transform 0.2s ease-in-out - 如果用 JS 切换 class，确保旧 class 和新 class 中只有你列出来的那几个属性有差异
- 别信“加了 transition 就一定动”，浏览器必须能读到起始值和结束值——中间不能被 JS 或 CSS 覆盖掉
timing-function 和 duration 怎么配才不僵硬
默认 ease 在按钮反馈里太“粘”，linear 又像机器人。真正自然的节奏要更细：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
- 按钮悬停推荐
ease-in-out：起始柔和、中段快、结尾收得稳 -
transform: scale()类动效，duration别超过0.25s，否则放大过程拖沓 - 低于
0.15s人眼难感知，高于0.4s易产生等待感；0.2s–0.3s是安全区间 - 慎用
cubic-bezier(0.175, 0.885, 0.32, 1.275)这类 overshoot 曲线——适合菜单展开，但按钮上容易“弹过头”
移动端和 JS 配合时最容易忽略的细节
过渡不是设完就完事。在 touch 场景或 JS 动态操作下，几个隐性条件不满足，动画就直接消失：
- 移动端有约
300ms的点击延迟，叠加transition-delay: 0.2s，用户会明显感觉“点了没反应” - JS 加 class 后立刻修改样式（比如先加
fade-in，再设el.style.opacity = 1），浏览器可能合并渲染，导致无过渡 - 补救方式：加一行
el.offsetHeight或void el.offsetWidth强制重排，让浏览器“看到”起始状态 - 服务端渲染页面，初始 HTML 必须带
opacity: 0样式，否则首屏会“闪一下再淡入”——这不是 bug，是解析顺序问题
最常被绕过的其实是“元素是否真的可绘制”：display: none、visibility: hidden、甚至 opacity: 0 都会让 View Transitions API 拍不到旧快照，过渡只剩新内容硬切。自然的前提，是旧元素得“在那儿”，哪怕只是 opacity: 0.999。
