Vue Element Admin 路由动画改造与避坑指南

后台管理系统做久了会有一种很微妙的手感差异功能一模一样的两套系统一套点起来顺一套点起来愣。差在哪往往就差在几十毫秒的过渡上。菜单点下去内容啪地直接换掉眼睛要重新找焦点这在一天点几百次的后台里是实打实的成本。Vue Element Admin 路由动画这套东西说白了就是给页面切换加一层符合直觉的缓冲让用户知道我点的是这一页它进来了。这套模板默认其实已经给你留了一小段淡入淡出的 CSS但绝大多数人要么没注意要么动了之后发现页面开始抖、图表变形、缓存失效然后干脆删掉。这篇就围绕这套脚手架从默认实现讲到按层级做左右滑动把坑一个个填平。1. 路由动画这件事先分清你在动谁1.1 transition 的六个类名和三个时间点很多人写动画是试出来的——改个类名刷新看看效果不对再改。这种方式在简单场景能用一旦牵涉到mode、appear、动态name就会彻底乱套。所以我建议先把 Vue 的transition在切换瞬间到底干了什么搞清楚这是后面所有调试的地基。一次元素切换Vue 会分三个阶段插类名。以namefade-transform为例Vue 2 的命名规则是阶段起始类名过程类名结束类名触发时机进入fade-transform-enterfade-transform-enter-activefade-transform-enter-to新元素插入前加前两个下一帧加-to并去掉-enter离开fade-transform-leavefade-transform-leave-activefade-transform-leave-to旧元素移除前加前两个下一帧加-to并去掉-leave关键点在于下一帧这个动作。浏览器必须先把-enter的初始状态渲染出来再在同一帧之后切换到-to才能产生过渡。如果你把初始值和结束值写在同一个类名里浏览器根本没机会看到两个不同状态动画自然不动。这是新手最常踩的第一个坑。进入过程的-active类名会贯穿始终它承担的职责是声明我要过渡哪些属性、多久、什么曲线也就是transition属性本身。结束状态的终值放在-to里。所以最标准的写法是.fade-transform-enter-active, .fade-transform-leave-active { transition: opacity 0.3s ease, transform 0.3s ease; } .fade-transform-enter { opacity: 0; transform: translateX(-20px); } .fade-transform-leave-to { opacity: 0; transform: translateX(20px); }Vue 3 把这套类名改成了-enter-from和-leave-from的语义化命名-enter-to和-leave-to保留。如果你的项目已经从 Vue 2 迁到 Vue 3而 CSS 还是老的-enter写法动画会完全不生效而且控制台不会报任何错。这个排查起来非常费时间记住这条能省你半天。还有一点Vue 判断过渡结束是靠transitionend事件。如果你在-active里写了transition: all .3s元素上同时有多个属性在变transitionend会触发多次Vue 内部虽然做了去重和最长时长计算但在某些浏览器组合下会提前结束或者拖长。明确写出属性名不用all这是我给自己定的规矩后面讲性能时还会再提。1.2 这套 admin 模板默认给的那套东西到底做了什么拿到脚手架之后先别急着改。打开src/layout/components/AppMain.vue默认长这样template section classapp-main transition namefade-transform modeout-in router-view :keykey / /transition /section /template script export default { name: AppMain, computed: { key() { return this.$route.path } } } /script配套的样式在src/styles/transition.scss里大概是transition: all .5s加左右各 30px 的位移。这就是它全部的默认实现一共不到二十行。但就是这二十行藏着三个决定后续所有行为的设定很多人改动画改了三天没改明白问题都出在这三处第一modeout-in。旧页面完全退场之后新页面才开始进场。这意味着两次动画是串行的中间会有一个瞬间容器里什么都没有。第二:keykeykey 取的是$route.path。第三transition包在router-view外面而keep-alive根本没出现在这里——模板的缓存逻辑在别处走的是另一套机制。先说时长。默认 0.5 秒在后台系统里偏长了。out-in 模式下用户点完菜单要等旧页面走完 0.5 秒新页面才开始进场再过 0.5 秒才稳定用户主观感受是点了没反应过一会儿才出来。而如果新页面在mounted里发接口那这 0.5 秒里连请求都还没发出去。我自己项目里统一压到0.26s进场、0.18s离场手感明显利落也没有闪一下的廉价感。这个数字不是拍脑袋的Material Design 的动效规范里中等规模元素的进出场时长区间就是 200 到 300 毫秒超过 400 毫秒人就会开始感觉卡。再说位移。30px 的水平位移配合透明度变化视觉上是从左边滑进来、往右边滑出去的对称效果。这在切换逻辑上是中性的——不管你是从哪进哪出方向永远一样。好处是不会出错坏处是没有空间感。后面第 4 节会专门讲怎么让方向跟着路由层级走。2. 方案选型CSS 过渡、JS 钩子还是引入动画库2.1 三条路的成本对照给路由切换加动效技术上至少有三条路可走。我在这三条路上都走过一遍最后回到最简单的 CSS但这个过程值得说清楚因为选错方案的代价不是多写几行代码而是后期没法维护。方案实现方式上手成本可控性适用场景CSS 类名过渡写-enter/-leave系列类名极低中受 CSS 能力限制淡入淡出、位移、缩放等常规效果JS 钩子beforeEnter/enter/afterEnter等八个钩子中高可操作 DOM 与状态需要配合业务逻辑、动态计算参数动画库GSAP、anime.js 等在钩子里调用高极高复杂编排、多元素错峰动画用 JS 钩子的典型场景是动画结束后要做事。比如离开动画播完再去销毁某个定时器或者进入动画结束后调用图表的resize()。这时候after-enter就派上用场了。而在钩子里操作 DOM 的写法能拿到el参数但要注意这个el在 out-in 模式下是隔离的不要在里面做依赖兄弟节点的操作。动画库我确实试过。当时的需求是页面卡片依次错峰淡入纯 CSS 要写一堆nth-child的transition-delay维护成本爆炸于是引入了 GSAP。效果确实好看但代价是打包体积多了几十 KB而且这套 admin 模板本身的交互密度很高动画库的 tick 和 Vue 的渲染节奏偶尔会打架出现动画播到一半组件已经销毁的报错。后来需求砍掉了库也删了。2.2 我为什么最后把动画库删了根本原因在于路由动画的本质是两个状态的交接不是一段可以自由编排的时间轴。用户点菜单这个动作触发的是路由变化路由变化触发组件销毁和创建动画只是这个过程的可视化包装。它天然是短时的、被动的、被打断的——用户完全可能在动画播到一半时点了另一个菜单。动画库擅长的是我主动发起一段精心编排的演出它假设动画会完整播完。一旦被打断你得手动 kill 掉 timeline还要处理残留的样式。而 CSS transition 天然支持打断新状态进来浏览器自动从当前计算值继续过渡到目标值不需要你写一行清理代码。所以我的结论很明确路由级别的页面切换动画只用 CSS。需要动画结束后做点什么用after-enter钩子。真正的复杂编排动画放在页面内部用动画库去做两者不要混在同一个元素上。2.3 out-in 与 in-out这一步选错后面全白搭mode这个属性只有两个值但选哪个直接决定了你会不会遇到布局抖动。modeout-in先走完离场再开始进场。同一时刻容器里只有一个页面。modein-out新页面先进场进来之后再让旧页面走。同一时刻容器里有两个页面并存。不写mode默认就是两个同时进行容器里同样有两个页面。听起来in-out更平滑实际上在后台系统里几乎不能用。原因是两个页面会同时在文档流里占位置。app-main是个普通块级容器两个页面依次排列容器高度瞬间翻倍页面会出现一次剧烈的上下跳动滚动条也会跟着抽一下。你必须给离场的那个元素加position: absolute让它脱离文档流然后还要处理宽度对齐、层级覆盖、父容器position: relative这一堆事。而out-in的代价是中间有一小段空白。这个空白期理论上等于离场动画时长但因为容器通常有min-height撑着用户看到的不是白屏而是内容淡出稍等一下新内容淡入。在 200 毫秒左右的量级上这个空窗几乎感知不到。我的建议是除非你有非常明确的理由否则老老实实用out-in。它帮你省掉了一整套绝对定位布局的麻烦而且动画顺序符合人脑的因果直觉——先离开再进入。3. 改造 AppMain从默认的淡入淡出到完全可控3.1 三层嵌套顺序transition、keep-alive、router-view后台系统必然要配缓存不然每次切回来都重新请求、重新渲染体验更差。加上keep-alive之后AppMain.vue的结构就变成了三层。这三层的顺序不是随便排的排错了会出两种完全不同的毛病。template section classapp-main transition namefade-transform modeout-in keep-alive :includecachedViews router-view :keykey / /keep-alive /transition /section /template script import { mapGetters } from vuex export default { name: AppMain, computed: { ...mapGetters([cachedViews]), key() { return this.$route.path } } } /scripttransition 必须在最外层keep-alive 在中间router-view 在最里层。这个顺序的理由是transition需要感知的是子节点有没有被替换它必须是直接父级keep-alive需要感知的是这个组件要不要被缓存它要包住真正的组件。如果反过来把keep-alive放外层transition就成了keep-alive的子节点缓存命中时keep-alive直接复用实例transition收不到切换信号动画就不会触发。这里还有一个真实的坑keep-alive的include匹配的是组件的 name 属性不是路由的 name。很多人给路由配了name以为就能缓存结果死活不生效。Vue 2 里组件 name 就是export default { name: UserList }那一行。Vue 3 用script setup写的组件name 靠编译器从文件名推断构建压缩之后可能和你想的不一样最稳的做法是显式声明script export default { name: UserList } /script script setup // 业务代码 /script或者用defineOptions({ name: UserList })。这个细节我在两个项目里踩过表现都是缓存像时灵时不灵实际上从来没灵过只是有些页面碰巧 name 对上了。3.2 key 用 path 还是 fullPath直接决定缓存是否失效这一小节值得单独拎出来说因为它是这套模板里最容易产生看起来没问题、用起来全是 bug的地方。router-view上加了:key意味着 key 变化时 Vue 会认为是不同的节点直接销毁重建。默认取$route.path也就是不含查询参数的路径。于是会出现两种情况第一种/user/1和/user/2用的是同一个详情组件。path不同key 不同组件会重建动画正常触发数据重新拉取——看起来是对的。但keep-alive的缓存是按 vnode 的 key 存的这两次会被存成两份缓存。用户连续点 20 个不同 id 的详情页就有 20 个组件实例常驻内存每一个里面可能还挂着定时器、ECharts 实例、事件监听。这是个缓慢累积的内存泄漏开发阶段完全看不出来上线跑一天才有人反馈越用越卡。第二种/list?page2和/list?page3。path都是/listkey 不变组件不会重建created不执行数据不会刷新。用户点了分页页面纹丝不动只有当前页组件的activated钩子被触发如果之前缓存过。很多人第一反应是分页坏了其实是 key 没变。我的处理原则是这样的场景key 取值理由普通列表页、表单页$route.path查询参数变化走组件内部逻辑不重建详情页按 id 区分$route.fullPath必须区分不同 id同时不进缓存需要缓存的详情页$route.path 组件内监听$route折中方案需要手动处理数据刷新如果整体切到fullPath一定要同步调整cachedViews的策略把详情类页面从include里排除掉否则内存会持续增长。这个排查我建议在开发阶段就加一个简单的监控写个定时器打印keep-alive的cache大小肉眼看着它涨比线上出问题强太多。3.3 CSS 落地类名、时长与参数换算CSS 部分我一般单独放一个文件跟着主样式一起引而不是塞在AppMain.vue的style scoped里。原因是过渡类名可能被多个层级的router-view复用放在 scoped 里会带上属性选择器容易失效。// 进入与离开共用过渡属性 .fade-transform-enter-active { transition: opacity 0.26s cubic-bezier(0.25, 0.8, 0.25, 1), transform 0.26s cubic-bezier(0.25, 0.8, 0.25, 1); } .fade-transform-leave-active { transition: opacity 0.18s cubic-bezier(0.4, 0, 1, 1), transform 0.18s cubic-bezier(0.4, 0, 1, 1); } .fade-transform-enter { opacity: 0; transform: translateX(-20px); } .fade-transform-leave-to { opacity: 0; transform: translateX(20px); }进场用cubic-bezier(0.25, 0.8, 0.25, 1)这是一条先快后慢的曲线元素冲进来的瞬间速度最快然后缓缓停住符合物体受阻力停下的直觉。离场用cubic-bezier(0.4, 0, 1, 1)先慢后快像是被吸走。两种曲线不一样动画就不对称视觉上有层次。如果进出用同一条曲线会感觉来回都很平缺一点生机。位移量从 30px 收到 20px也是配合时长缩短的。时长越短、位移越大速度感就越强烈容易显得急。20px 在 1280 宽的屏上大约是一个图标宽度够表达方向又不至于抢注意力。另外一个容易被忽略的细节.app-main容器本身要给一个最小高度。.app-main { min-height: calc(100vh - 50px); // 50px 是 navbar 高度 position: relative; overflow-x: hidden; box-sizing: border-box; padding: 16px; }min-height是为了对抗 out-in 模式的空窗期——离场元素已经销毁新元素还没进来容器没内容就没高度整个页面会向上缩一下再弹回来。overflow-x: hidden是为了挡住translateX带来的横向溢出下面第 5 节会详细说。这两行看起来不起眼但它们是动画有没有抖动的分水岭。4. 进阶打法按路由层级做左右滑动4.1 方向怎么判断才靠谱默认的固定方向动画有个问题用户从列表页点进详情页看到的是从左边滑进来从详情页点返回看到的还是从左边滑进来。方向不变用户脑子里那套进去像往里走、返回像往后退的空间模型就建立不起来。想要方向跟着层级走核心是判断这次是进入更深一层还是退回上一层。常见有四种判断依据我按可靠性排序第一种比较路径层级深度。把path按/切开过滤空串比长度。/user是 1/user/detail是 22 大于 1 就是进入反之是返回。这个方案零配置但对path的层级结构有要求如果路由是扁平设计的/user-detail和/user平级就判断不出来。第二种比对自己的meta.level。每个路由手动标一个层级数字读meta比较。最准确但要维护路由一多容易标错。第三种判断包含关系。to.path.startsWith(from.path)为真说明是从父路径进入子路径。这个判断在列表进详情的经典场景里非常准而且不用配置。缺点是兄弟路由之间跳转/user到/role会被判定为返回需要单独处理。第四种比对历史栈位置。用history.state.position或者自己维护一个栈。这个最符合浏览器的真实语义但实现复杂度最高而且tagsView点击切换时不走历史栈会漏掉。我自己项目里用的是第三种为主、第二种兜底的组合先判断包含关系判断不出来再看meta.level两者都没有就给中性淡入。这套逻辑写了三十行不到覆盖了 95% 的跳转场景。4.2 方向状态机落地的两种写法方向判断出来了接下来是怎么把它变成过渡类名。最直觉的写法是在watch $route里改一个transitionName绑到transition :name...上。我先说这个写法的问题再说稳妥的做法。问题在于时序。watch $route触发的时候路由已经切过去了Vue 也已经开始渲染新的router-view。transition在开始离场时读取name如果这一刻name已经被改成了新值那么离场动画用新类名、进场动画也用新类名——方向就乱了。表现是点进去两个页面都往左滑或者离场完全没动画。稳妥的做法是在路由变化之前就把方向算好。有两种落地方式// 方式一全局前置守卫里算存到模块级变量 // router/index.js let direction fade router.beforeEach((to, from, next) { const toDepth to.path.split(/).filter(Boolean).length const fromDepth from.path.split(/).filter(Boolean).length direction toDepth fromDepth ? slide-left : toDepth fromDepth ? slide-right : fade next() }) export function getDirection() { return direction }// AppMain.vue 的 computed 里读 computed: { transitionName() { return getDirection() } }前置守卫在路由确认之前执行此时组件还没开始离场name的更新发生在离场开始之前——这里的时序是安全的因为守卫整体在这一轮渲染之前跑完。方式二是把方向放在meta里通过路由配置直接声明这个页面应该从哪边进来不依赖判断逻辑{ path: detail/:id, name: UserDetail, meta: { transition: slide-left } }这种方式最可控产品经理说这个弹层页要从右边推出来你直接在meta里写死不用跟它博弈。缺点是每加一个页面都要配一次容易忘。实际项目里我是混着用的meta.transition优先没配才走自动判断。这样常见页面自动生效特殊页面手动覆盖。对应的 CSS// 往左推新页面从右侧进旧页面往左侧出 .slide-left-enter-active, .slide-left-leave-active { transition: opacity 0.26s ease, transform 0.26s ease; } .slide-left-enter { opacity: 0; transform: translateX(24px); } .slide-left-leave-to { opacity: 0; transform: translateX(-24px); } // 往右推方向完全相反 .slide-right-enter-active, .slide-right-leave-active { transition: opacity 0.26s ease, transform 0.26s ease; } .slide-right-enter { opacity: 0; transform: translateX(-24px); } .slide-right-leave-to { opacity: 0; transform: translateX(24px); }注意slide-left和slide-right的方向是反的。这里最容易写错进入子页时新页面应该从右边进来、旧页面向左边退出去因为深入在视觉上等于向右推进。返回时反过来。很多人凭直觉写反了用起来会觉得怪但说不上哪怪。4.3 登录页到首页的动画为什么管不到这个问题我遇到过至少两次每次都是同事来问我改了半天动画登录进去那一下就完全没效果。原因在于层级结构。这套模板的App.vue是这样template div idapp router-view / /div /template根级router-view渲染出来的是Layout带侧边栏那套框架或者Login。而AppMain.vue在Layout内部它管的是框架内的内容区。于是就有三种切换登录页 → 首页根router-view切换Layout整个替换掉Login。AppMain的动画管不到因为AppMain在切换前根本不存在。首页 → 用户列表Layout不动只有内部router-view切换。AppMain的动画正常生效。首页 → 退出登录又是根router-view切换。想让登录进首页也有动画得在App.vue的根router-view上也加一层transition。但加之前要清楚一件事这会让两层动画叠加。用户从登录进首页根层播一次AppMain层的首次渲染也可能触发一次取决于是否设appear两个动画同时播会有点乱。我的处理是根层只做纯透明度过渡用fade这个名字时长 200 毫秒不做位移。AppMain层正常做位移。这样视觉上是整体淡入 内容区轻微位移层次清楚。!-- App.vue -- template div idapp transition namefade modeout-in router-view / /transition /div /template要注意根层这个transition包裹的是Layout或Login组件它们都是单根节点没问题。但如果哪天有人把App.vue改成多根结构Vue 会直接报错动画失效还会在控制台刷一堆警告。5. 真实翻车现场六类高频问题排查5.1 横向滚动条突然冒出来这个问题的出现率高到离谱。加了transform: translateX(-20px)之后元素往左移出可视区浏览器认为内容超出了容器宽度底部横向滚动条就出现了——或者更糟整个页面能左右拖动。根因是对transform溢出行为的理解偏差。transform不改变布局尺寸但会影响溢出计算。元素虽然还在文档流里占原来的位置它被平移后的绘制区域确实伸到了父容器外面。浏览器是否裁掉这部分、是否产生滚动条取决于父级的overflow设置。解决方案是给AppMain的父级或者它本身加overflow-x: hidden。但要注意加在谁身上。加在.app-main上是最直接的。如果加完还有残留往上一层找可能是Layout的main-container也需要加。还有一种情况是加完之后页面的纵向滚动条被裁掉了——那是因为overflow-x: hidden在某些浏览器里会连带影响overflow-y的计算安全的写法是.app-main { overflow-x: hidden; overflow-y: visible; }不过overflow-y: visible和overflow-x: hidden组合是非法值浏览器会把visible强制改成auto。所以更稳的做法是只在动画期间临时隐藏横轴.app-main { transition: overflow-x 0s; } .app-main:has(.fade-transform-enter-active) { overflow-x: hidden; }这个写法用到了:has()兼容性要评估。另一个思路是直接给body加overflow-x: hidden简单粗暴但有效代价是全站都禁用了横向滚动。后台系统基本没有横向滚动的需求我一般就这么干。提示排查这类问题时先在浏览器里用document.documentElement.scrollWidth和clientWidth比较一下看看溢出的是哪个层级比一层层试overflow快得多。5.2 页面高度塌陷、白屏一瞬modeout-in的空窗期容器里没有内容。如果.app-main没有min-height容器高度会瞬间归零整个页面从 800px 缩到 50px 再弹回来。用户看到的是内容没了页面抖了一下内容又回来了。这个问题在长列表页特别明显。因为长列表页的高度可能有两三千像素切走时高度从 3000 掉到 50切回来再涨到 3000滚动条位置也跟着乱跳。解决分三层。第一层是给容器min-height保证空窗期还有一个基础高度。第二层是搞定滚动位置在路由的scrollBehavior里统一回到顶部// router/index.js scrollBehavior(to, from, savedPosition) { if (savedPosition) { return savedPosition } return { x: 0, y: 0 } }第三层是给keep-alive缓存页面的滚动位置做恢复。这块要跟业务商量——有的产品希望返回列表页时保留滚动位置有的希望回到顶部不能默认。还有一个更细的坑min-height用100vh计算时在移动端浏览器里会因为地址栏的伸缩而跳变。后台系统一般跑在桌面端影响不大但如果你的系统要在平板上用建议改成100%配合父级的固定高度或者用dvh单位。5.3 动画不触发或者只在第一次触发只在第一次触发这个描述非常典型几乎可以锁定两个原因。第一个原因key 没变。前面说过router-view的 key 不变Vue 认为是同一个节点直接复用不触发替换transition自然收不到信号。表现为第一次进入某个页面有动画之后再点同一个路径的其他参数画面直接跳变。第二个原因keep-alive命中了缓存。缓存复用意味着组件实例没被销毁重建如果此时 key 又没变transition认为子节点没变化。这种情况通常发生在两个不同的菜单指向同一个组件的场景比如我的消息和待办事项都渲染MessageList组件只是路由参数不同。排查方法很简单在transition上加before-enter和before-leave两个钩子打日志。如果before-leave根本没打说明离场就没开始问题在 key 或缓存如果before-leave打了但before-enter没打说明卡在了 out-in 的等待阶段通常是离场动画的transitionend没触发——这种情况多半是离场元素上有别的动画比如子元素的 CSS 循环动画干扰了事件。还有一种非常隐蔽的过渡的元素上display: none。有些页面用v-show控制根容器的显示状态如果切换瞬间它是隐藏的浏览器不会对隐藏元素执行过渡Vue 会直接跳过动画。这种问题看日志看不出来得看 DOM 结构。5.4 图表变形、弹窗错位、下拉框飘走这类问题统称过渡期间的定位异常根因只有一个transform会创建新的包含块。CSS 规范里一个元素只要有了transform值非none它就变成了后代position: fixed元素的包含块。也就是说过渡期间那些本该相对视口定位的弹窗、抽屉、全屏遮罩会改成相对这个正在做动画的容器定位。表现出来就是用户在页面切换的 200 毫秒里点开了一个弹窗弹窗位置偏了几十像素或者全屏遮罩只盖住了内容区没盖住侧边栏。等动画结束transform恢复成none弹窗又啪地跳回正确位置。彻底解决的办法是让这些浮层挂到body上脱离这个容器。Element UI 的el-dialog有append-to-body属性el-select和el-dropdown默认就是挂 body 的。所以对el-dialog记得加append-to-body对自定义的浮层组件也做同样处理。这是组件库早就替你想好的方案只是很多人不看文档。图表的问题更麻烦。ECharts 初始化时读取容器宽高如果容器处在transform状态getBoundingClientRect()返回的是变换后的尺寸图表会按错误的宽高渲染出现模糊或者比例失调。有两种处理。第一种是进场动画只用opacity和translateX不用scale位移不改变元素的尺寸图表读到的宽高是对的。第二种是在组件的activated或者动画结束钩子里主动resize()// AppMain.vue methods: { handleAfterEnter() { // 通知所有图表重新计算尺寸 window.dispatchEvent(new Event(resize)) } }transition namefade-transform modeout-in after-enterhandleAfterEnter用全局resize事件是个偷懒但有效的办法因为大多数图表组件都监听了window.resize。缺点是会触发全站所有图表的重新计算页面里图表多了会有性能损耗。更精确的做法是用事件总线或者provide/inject但那是另一篇文章的事。5.5 问题速查表把上面这些整理成一张表遇到问题时从上往下对一遍能省掉大量瞎试的时间。现象最可能的原因排查动作处理方式完全没动画类名写错Vue 3 用了 Vue 2 的类名检查-entervs-enter-from按框架版本改类名只有第一次有动画key 没变化打印路由 key 值换 key 取值或手动触发动画播一半卡住离场元素上有其他动画干扰检查子元素 CSS 动画子元素动画加pointer-events: none底部出现横向滚动条translateX溢出对比scrollWidth和clientWidth父级加overflow-x: hidden切换时页面抖动容器无min-height观察空窗期容器高度加min-height兜底弹窗位置偏移transform创建了包含块检查浮层是否挂 body加append-to-body图表模糊或比例错过度期间读取了变换后尺寸检查是否用了scale改用位移或主动 resize缓存页面数据不刷新key 不变 缓存命中检查include和 key调整缓存策略6. 性能与可访问性什么时候该主动关掉动画6.1 属性选择只碰 transform 和 opacity页面上能触发动画的 CSS 属性有一大堆但真正便宜的只有两个transform和opacity。原因在浏览器的渲染流水线。一帧的生成大致分五步样式计算、布局、绘制、合成、显示。改width、height、margin、top、left这些属性浏览器必须重新做布局整条流水线重走一遍。改background-color、box-shadow这类可以跳过布局但要重绘。只有transform和opacity浏览器可以把元素提到独立的合成层由 GPU 单独处理不触发主线程的布局和绘制。所以那套老代码里的transition: all .5s如果真的去改一个宽高在低端机器上就是灾难。all更麻烦的地方在于它监听了所有可动画属性浏览器内部要做更多的工作来判断哪些属性真正变了。正确的写法是明确列出属性// 不要这样 transition: all 0.3s; // 要这样 transition: opacity 0.26s ease, transform 0.26s ease;关于will-change很多人喜欢到处加觉得能让动画更流畅。实际上will-change: transform是告诉浏览器提前给我升层这是一次性的成本——会永久占用一块显存。页面里几十个元素都加will-change显存直接爆掉反而更卡。正确用法是只在动画进行期间加动画结束就移除。transition的-active类名天然适合干这个.fade-transform-enter-active, .fade-transform-leave-active { will-change: transform, opacity; }-active类名只在过渡期间存在过渡结束自动移除will-change也跟着消失内存能正常释放。这个用法是我见过最优雅的will-change实践。6.2 减少动效偏好与低端设备降级有一类用户是被所有人忽略的前庭功能障碍人群。大幅度的位移动画会让这部分人产生眩晕、恶心。操作系统层面早就提供了开关Windows 的显示动画、macOS 的减弱动态效果、iOS 和 Android 都有对应设置浏览器会把它暴露成媒体查询prefers-reduced-motion。给后台系统加上这段成本极低media (prefers-reduced-motion: reduce) { .fade-transform-enter-active, .fade-transform-leave-active, .slide-left-enter-active, .slide-left-leave-active, .slide-right-enter-active, .slide-right-leave-active { transition-duration: 0.01ms !important; } .fade-transform-enter, .fade-transform-leave-to, .slide-left-enter, .slide-left-leave-to, .slide-right-enter, .slide-right-leave-to { transform: none !important; opacity: 1 !important; } }注意时长不能写0s。写0s的话transitionend事件不会触发Vue 内部靠这个事件判断过渡结束会导致元素卡在过渡状态后续的路由切换全部乱掉。写0.01ms是个经典技巧足够短到看不见又能正常触发事件。除了这个媒体查询还有一个更实际的降级场景低端办公电脑。后台系统的用户环境你控制不了有人用的是十年前的机器还开着十几个浏览器标签页。这种情况下即使是 GPU 加速的动画也可能掉帧。我的做法是在应用启动时做一次极简的性能探测把结果存到sessionStorage动画组件读这个值决定用不用动画。探测逻辑不复杂比如测量连续两次requestAnimationFrame的时间差超过 32 毫秒说明帧率低于 30就可以判定为弱设备。// utils/perf.js export function detectWeakDevice() { const cached sessionStorage.getItem(__weak_device__) if (cached ! null) return cached 1 let frames 0 let start 0 let end 0 function step(timestamp) { if (!start) start timestamp end timestamp frames if (frames 20) { requestAnimationFrame(step) } else { const fps (frames - 1) / ((end - start) / 1000) const weak fps 30 sessionStorage.setItem(__weak_device__, weak ? 1 : 0) } } requestAnimationFrame(step) }这个方法有争议——它在页面加载时就跑了 20 帧的探测本身就是一点开销。而且首屏渲染期间浏览器本来就很忙测出来的帧率天然偏低可能把正常设备误判成弱设备。所以我把阈值调得很低fps 30才判定而且结果缓存在sessionStorage整个会话只测一次。6.3 一套自适应的降级写法把上面这些揉在一起最终的AppMain.vue大概是这样template section classapp-main :class{ no-motion: !motionEnabled } transition :nametransitionName modeout-in after-entersyncCharts keep-alive :includecachedViews router-view :keykey / /keep-alive /transition /section /template script import { mapGetters } from vuex import { getDirection } from /router import { detectWeakDevice } from /utils/perf export default { name: AppMain, data() { return { motionEnabled: true } }, computed: { ...mapGetters([cachedViews]), key() { return this.$route.path }, transitionName() { return this.motionEnabled ? getDirection() : } }, created() { const reduced window.matchMedia((prefers-reduced-motion: reduce)).matches const weak detectWeakDevice() this.motionEnabled !reduced !weak }, methods: { syncCharts() { if (!this.motionEnabled) return this.$nextTick(() { window.dispatchEvent(new Event(resize)) }) } } } /script关键点是把transitionName变成空字符串时transition会退化成无动画的普通渲染直接用display切换。这个降级是彻底的不是把时长调到极短——极短还是会有样式计算成本空名字是真正跳过整个过渡流程。syncCharts放在after-enter里且套了一层$nextTick是因为进场动画刚结束时组件的mounted可能还没跑完尤其是异步组件直接派发事件可能打在还没初始化的图表上。加一个 tick 更保险。这套写法在我手上跑了三个后台项目兼容Vue 2.6到Vue 2.7用户没反馈过动画相关的异常。唯一需要注意的是getDirection那个模块级变量在Vue 2.7的composition API里如果要做响应式得包一层reactive否则视图不更新。我当时踩了这一下表现是方向偶尔不生效改了reactive之后正常。最后分享一个我在实际项目里养成的小习惯给动画加一个全局开关放在用户设置里存到localStorage。有些老用户就是不喜欢动效让他们自己关掉比你猜他们喜欢什么强。实现成本就三行代码transitionName那里多读一个判断就行但能省掉不少能不能别动的沟通成本。