企业官网建设流程全解析

开头（≥200字）设计：

做前端这么多年，我踩过最深的坑之一，就是"一口气把所有东西都加载完"。早年间做一个数据可视化项目，页面首屏要同时渲染上千个图节点，结果就是白屏三四秒、卡顿掉帧、用户直接关掉页面。后来我把渲染逻辑拆开，改为用户滚动到哪、点开哪个面板，才真正加载对应的资源和数据，首屏时间从 4.2 秒降到了 1.3 秒。这就是动态加载的价值——不是把所有东西一次性塞给用户，而是把资源和数据拆成小块，在用户真正需要的那一刻再加载、再渲染。

这篇文章想聊聊动态加载这项关键技术，它到底解决了什么问题、底层逻辑是什么，以及在我实际工作中是怎么落地的。我会重点结合最近在做的一个 Vue 项目——基于 relation-graph 的关系图谱上钻下钻场景，讲讲动态组件加载、异步数据拉取、节点按需渲染这套完整方案是怎么设计和实现的。适合正在做性能优化、或者遇到页面卡顿、首屏加载慢问题的前端开发者参考。

1. 动态加载的本质：把"一次性做完"拆成"按需再做"

很多人对动态加载的理解停留在"延迟加载"这个表面概念上，觉得无非就是把 import 变成动态 import、把请求往后挪一挪。但实际上，动态加载背后是一整套资源调度思路的转变，它改写了"应用什么时候该做什么事"这个基本问题。

1.1 三个收益维度：首屏时间、带宽消耗、渲染开销

先说最直观的收益，提性能必提的三个指标。

首屏时间。一个大型应用如果把所有路由组件、图表库、表格插件都打进一个 bundle，用户在打开首页时就必须下载完整个包才能开始渲染。动态加载把 bundle 切碎之后，首页只需要下载首页相关的代码，剩下的模块等用户跳转过去再下载。首屏时间因此不是从"所有资源就绪"开始算，而是从"当前页面资源就绪"开始算。

带宽消耗。移动端场景尤其明显，用户可能不会访问 80% 的功能模块，那 80% 的代码在首次访问时完全是在烧流量。动态加载让用户只为"实际用到的功能"买单，这部分流量节省通常可以达到 60% 以上。

渲染开销。数据层面也一样，如果一个页面有 1 万个图节点，你一次性全部渲染进 DOM，浏览器布局和绘制的时间会暴涨。动态加载可以把渲染任务切碎——屏幕里看得到的先渲染，看不等等的等用户滚动或点击时再渲染。这一层其实是"数据加载"与"渲染调度"的结合，也是很多前端项目里最容易忽略的。

1.2 动态加载不是银弹：什么时候该用，什么时候不该用

我必须泼一盆冷水，动态加载不是所有场景的万能药。它有三个明显的代价：

• 额外的等待时延。用户点击某个功能时，如果模块较大，需要现场下载并执行，会出现短暂的加载状态。这个体验如果处理不好，比一开始就全部加载更糟糕。
• 复杂度上升。代码要被拆成多块，需要处理加载状态、错误重试、缓存失效、模块间的依赖关系，这对工程化能力提出了更高要求。
• 某些场景反而变慢。如果应用体量本身很小、所有代码压缩后不到 100KB，动态加载带来的请求往返开销和分包管理成本，反而会让整体体验变差。

所以我的判断标准一般是：应用首屏代码超过 300KB（gzip 后）或者首屏需要渲染大量数据时，动态加载能获得正向收益；否则，老老实实一把梭就行。理解了什么时候该用，再往下聊具体的技术手段，才有意义。

2. 动态加载的四种打开方式：代码分包、路由懒加载、组件异步化、数据按需拉取

动态加载在实践中不是单一技术，而是四个层面叠加起来的效果。很多人只知道其中一两种，但真正做得好的项目，往往是四层一起用。

2.1 代码层面的分包：Webpack/Vite 如何把 bundle 拆开

代码分包是动态加载的基石。Webpack 和 Vite 在处理动态 import() 语法时，会自动把它变成一个单独的分包，这叫 code splitting。

// 静态导入：所有代码打成一个包，首屏全量加载 import { ChartRenderer } from '@/components/ChartRenderer' // 动态导入：单独打成 chart-renderer.js，只有执行到这里时才加载 const ChartRenderer = () => import('@/components/ChartRenderer.vue')

Vite 在底层使用 Rollup，对动态 import 的支持非常好，你甚至不需要额外的配置，只要在代码里把 import() 写出来，构建时就会自动分隔。Webpack 则需要配合splitChunks配置，把公共依赖单独提炼出来，避免多个分包重复打包同一个库：

// vite.config.js export default defineConfig({ build: { rollupOptions: { output: { manualChunks: { 'vendor-react': ['react', 'react-dom'], 'vendor-chart': ['echarts', 'relation-graph'] } } } } })

这样做的效果是什么？以我最近的项目为例，全量打包产物是 2.8MB（gzip 后 760KB），分包之后，首屏只需要加载 280KB（gzip 后 90KB），剩下的 2.5MB 都是用户访问到具体功能模块时才按需下载。这就是"资源跟着操作走"。

2.2 路由懒加载：页面级动态加载的标准姿势

路由懒加载是动态加载里最成熟、最标准的一种落地方式。Vue Router 和 React Router 都直接支持组件懒加载。

// router/index.js const routes = [ { path: '/dashboard', name: 'Dashboard', component: () => import('@/views/Dashboard.vue') }, { path: '/graph-analysis', name: 'GraphAnalysis', component: () => import('@/views/GraphAnalysis.vue') } ]

从"用户访问路由"这个天然边界来切分代码，是最自然的。每个页面一个 chunk，互不干扰。我在项目中还会配合路由元信息做一些额外处理，比如预加载：

// 用户 hover 到导航菜单时就预加载，点击时直接渲染，几乎无感知 router.beforeEach((to, from, next) => { if (to.meta.preload) { const component = () => import(`@/views/${to.meta.componentName}.vue`) component() // 触发加载 } next() })

这里要提一个经验：不要把路由懒加载当成唯一的手段。它只做到了页面级别的按需，但如果一个页面内部有多个重量级组件，页面打开时仍然会把所有重量级组件一次拉下来。这时候就需要第三层——组件级异步加载。

2.3 组件异步化：弹窗、抽屉、图表组件都要懒加载

组件级异步加载解决的是"页面内局部组件的按需加载"问题，通常和显隐控制绑定。最常见的就是弹窗、抽屉、复杂图表组件——它们在页面渲染时不需要立即出现，只有当用户触发某个操作时才需要。

Vue 3 的defineAsyncComponent是这一层的核心 API：

<script setup> import { defineAsyncComponent, ref } from 'vue' // 只有弹窗打开时才加载 FormEditor const FormEditor = defineAsyncComponent(() => import('@/components/FormEditor.vue')) const showEditor = ref(false) </script> <template> <button @click="showEditor = true">打开编辑器</button> <FormEditor v-if="showEditor" :data="currentData" /> </template>

有人会问：v-model控制显隐 + 异步组件有什么好处？好处是 FormEditor 组件及其依赖的第三方库（比如富文本编辑器、Markdown 解析器）不会出现在页面主 chunk 里，而是在用户点击按钮的那一刻才开始下载。对于不常使用编辑功能的用户来说，这部分流量和解析成本完全省掉了。

同样的思路也适用于图表。ECharts、relation-graph 这类图形库体积非常大，如果页面内嵌图表组件，我一般都会用异步组件包裹。但要注意一点：异步组件的加载状态必须处理好。defineAsyncComponent提供了loadingComponent和delay配置，可以避免加载闪烁：

<script setup> import { defineAsyncComponent } from 'vue' const GraphChart = defineAsyncComponent({ loader: () => import('@/components/RelationGraph.vue'), loadingComponent: () => import('@/components/LoadingPlaceholder.vue'), delay: 200, // 延迟 200ms 再显示 loading，避免快速加载时的闪烁 timeout: 10000 // 超过 10s 认为加载失败 }) </script>

2.4 数据按需拉取：动态加载的最后一块拼图

代码层面的加载解决了"代码要不要下载"的问题，但用户真正感知到的卡顿，很多时候来自"数据要不要一次性拉取"。动态加载的最后一层，就是把数据请求也切成小块。

拿我最近做的 relation-graph 项目来说，最开始我把整张图的几千个节点一次性从后端拉回来，一次性灌给组件，结果有两个明显的毛病：第一，接口响应很慢，要等好几秒；第二，graph 组件渲染几千个节点和边，浏览器直接卡到 20 帧以下。后来改成按需加载——初始只拉根节点和一级子节点，用户双击某个节点展开下钻时，再动态请求该节点的子节点。页面的 CPU 占用从 90% 降到 20%，交互流畅度完全不同。

数据按需拉取的实现核心在于：把"全量查询"改成"分层/分页查询"，把"一次性 setData"改成"增量 appendData"。这个思路在关系图谱、树形表格、无限滚动列表等场景里是通用的。

3. 实战拆解：Vue + relation-graph 实现上钻下钻动态加载

这一节是全文的重头戏。我拿一个真实项目来讲：用 Vue 3 + relation-graph 做企业组织架构图谱，支持双击节点下钻查看子部门、单击面包屑上钻回到上级。整体数据量大约 1 万多个节点，如果全量加载，页面直接卡死；用动态加载后，任意时刻内存中只保留 200 个左右节点，渲染毫无压力。

3.1 需求场景与方案选型：为什么选 relation-graph

先简单介绍下 relation-graph，这是一个基于 SVG 的关系图谱组件，支持自定义节点内容、自定义样式、节点展开收起、拖拽缩放等能力。相比 ECharts 的 graph 系列，relation-graph 的 API 更贴近"节点-边-画布"的操作模型，尤其适合做组织架构、知识图谱、流程图这类需要交互编辑的场景。

在"上钻下钻动态加载"这个需求面前，relation-graph 有一个明显的优势：它支持增量式数据更新，也就是通过graphInstance.appendData()方法向已有图谱中追加节点和边，而不需要重新构建整张图。这正好匹配"逐层探索"的数据交互模式。

方案设计分三层：

• 数据层：后端提供三类接口——getRootNodes()获取根节点、getChildrenById(id)获取某节点的直接子节点、getParentById(id)获取上级节点链路。
• 状态层：前端维护一个loadedNodes集合，记录哪些节点的子节点已经加载过，避免重复请求。
• 渲染层：relation-graph 实例负责增量渲染，每次只新增数据，不重绘全图。

3.2 初始化：只渲染第一层数据

首屏只调用一次getRootNodes，拿到根节点和它的直接子节点，作为图谱的初始数据。这一步非常轻量，接口返回的 JSON 通常只有几十 KB。

import RelationGraph from 'relation-graph' import { ref, onMounted } from 'vue' const graphRef = ref() const graphInstance = ref() // 记录已加载过子节点的节点 id，避免重复请求 const loadedNodes = new Set() async function initGraph() { // 获取根节点以及一级子节点 const { data } = await api.getRootNodes() const graphData = { rootId: data.rootId, nodes: data.nodes, lines: data.lines } // relation-graph 的 setJsonData 是全量设置数据 graphInstance.value.setJsonData(graphData) // 记录这些节点的子节点已经加载过 data.nodes .filter((node) => node.hasChildren) .forEach((node) => loadedNodes.add(node.id)) } onMounted(() => { graphRef.value.setGraphRef(graphInstance) initGraph() })

这里有个很关键的细节：loadedNodes里记录的不是所有节点，而是"已经加载过子节点的节点"。每次初始化后，我把所有有子节点且子节点已经展示出来的节点 ID 记录下来，后面下钻时先查这个集合，命中就跳过请求。

3.3 下钻：双击节点后动态追加子节点数据

relation-graph 提供了节点双击事件@node-dblclick，我在事件回调里做下钻处理。核心逻辑是：

1. 判断该节点是否在loadedNodes里，如果在，说明子节点已经加载过，直接跳过；
2. 如果不在，调用getChildrenById(id)获取直接子节点，然后通过appendData增量追加到图谱中；
3. 追加完成后把节点 ID 加入loadedNodes，防止重复请求。

async function handleNodeDblClick(node) { // 节点对象里包含 id 和业务数据 const nodeId = node.id // 已经加载过的节点，直接返回，不发请求 if (loadedNodes.has(nodeId)) { return } // UI 上先给节点加一个 loading 状态，提升交互反馈 graphInstance.value.updateNode({ id: nodeId, data: { loading: true } }) try { const { data } = await api.getChildrenById(nodeId) const newData = { nodes: data.nodes, lines: data.lines } // 增量追加到图谱，而不是全量重绘 graphInstance.value.appendData(newData) loadedNodes.add(nodeId) } catch (error) { console.error('加载子节点失败', error) // 失败时给用户一个轻提示 } finally { graphInstance.value.updateNode({ id: nodeId, data: { loading: false } }) } }

appendData是 relation-graph 专门为增量场景提供的 API，它内部会做新旧节点去重、自动连线等处理。这一步做完，用户双击哪个节点，哪个节点的子节点就会被"现场"拉取并渲染出来——这就是动态加载在该场景下的核心体验。

3.4 上钻：点击面包屑回到上级链路

下钻容易做，上钻反而容易被忽略。很多人在做动态图谱时只实现了"不断展开"，忘了提供关闭/回退通道。上钻的实现思路是：维护一个"当前路径链"，用户点击面包屑中的某个节点时，把图谱重置为以该节点为根的子图。

// 维护当前路径链，例如 ['A公司', '技术部', '前端组'] const currentPath = ref([]) function handleCrumbClick(index) { const targetId = currentPath.value[index].id // 将图谱重置为目标节点及其一级子节点 resetGraph(targetId) currentPath.value = currentPath.value.slice(0, index + 1) } async function resetGraph(nodeId) { const { data } = await api.getChildrenById(nodeId) const graphData = { rootId: nodeId, nodes: [ // 目标节点本身 + 一级子节点 ...data.parentChain, ...data.nodes ], lines: data.lines } graphInstance.value.setJsonData(graphData) }

上钻时我用了setJsonData（全量重置），而不是appendData，因为上钻意味着回到某个已知层级，需要把之前下钻出来的更深层节点清掉。这里想提醒一句：如果你的业务里既有上钻场景又有下钻场景，一定要分清楚哪些操作是全量重置、哪些操作是增量追加。搞反了，图谱要么乱掉，要么出现"死节点"残留。

3.5 结合动态组件加载：整个图谱区域做成异步组件

除了数据层的按需拉取，我在代码层面也做了配合。因为 relation-graph 本身是一个体积不小的组件库（压缩后约 300KB），如果它跟着主页面一起打包，首屏同样会被拖慢。所以我将整个图谱区域封装成了异步组件。

<!-- ParentView.vue --> <script setup> import { defineAsyncComponent, ref } from 'vue' // relation-graph 组件库及其图谱逻辑都放进异步分块 const RelationGraphPanel = defineAsyncComponent(() => import('@/components/RelationGraphPanel.vue') ) const showGraph = ref(false) </script> <template> <div> <button @click="showGraph = true">查看组织架构图</button> <RelationGraphPanel v-if="showGraph" /> </div> </template>

这样改动之后，首页 bundle 里完全不包含 relation-graph 的代码。用户只有真正点击"查看组织架构图"后，约 300KB 的组件代码才开始下载，配合loadingComponent做一个骨架占位，体验几乎是无感的。

4. 动态加载落地时的四个深坑：加载闪烁、竞态、缓存失效、异常兜底

动态加载听起来很美好，但每一个"按需"背后都藏着工程问题。我在这类项目里踩过不少坑，下面这几个是最常见的，列出来希望对你有用。

4.1 加载闪烁与"一闪而过"的 loading

异步组件如果加载很快（比如 200ms 以内），loading 组件一闪而过，视觉上反而会觉得突兀。解决办法是在defineAsyncComponent里设置delay，只有加载超过一定时间才显示 loading。这个值我一般设 200ms 左右——200ms 以内的加载用户几乎无感，不需要额外提示。

数据请求也有同样问题。如果每次点击下钻都显示 loading 转圈，即使接口只花了 100ms，用户也会觉得"卡了一下"。我的做法是：如果预计请求很快，就先给节点一个微弱的"展开中"效果（比如节点透明度降低 20%），而不是全局 loading；如果超过 500ms 没有返回，再显示完整 loading 状态。这个分层反馈策略，实测下来体验好了很多。

4.2 竞态处理：用户连续点击和快速上下钻

动态加载最常见的 Bug 就是竞态——用户快速双击多个节点，多个请求同时发出，后返回的请求可能先到达，导致图谱数据错乱。

我的处理方案是为每个节点加一个"请求版本号"：

const requestMap = new Map() async function handleNodeDblClick(node) { const nodeId = node.id if (loadedNodes.has(nodeId)) return // 同一个节点只允许一个请求在进行中 if (requestMap.has(nodeId)) return const controller = new AbortController() requestMap.set(nodeId, controller) try { const { data } = await api.getChildrenById(nodeId, { signal: controller.signal }) if (!controller.signal.aborted) { graphInstance.value.appendData(data) loadedNodes.add(nodeId) } } finally { requestMap.delete(nodeId) } }

另外，如果用户快速上钻（重置图谱）后，之前下钻的请求才回来，这也会造成"旧数据写入新图谱"的脏数据问题。针对这种情况，我会在resetGraph里统一 abort 掉所有进行中的请求：

function abortAllRequests() { requestMap.forEach((controller) => controller.abort()) requestMap.clear() }

4.3 缓存策略：什么时候用缓存，什么时候必须重新拉

动态加载的缓存策略是整个方案里最容易被低估的部分。拿上钻下钻来说，如果用户下钻了某个节点，又上钻回去，再双击同一个节点下钻——这时候要不要重新请求？

我最初的做法是直接命中loadedNodes，不发请求，结果发现数据可能已经过期。因为组织架构的人员变动是实时的，用户上钻后再次下钻，看到的可能是几分钟前的旧数据。

最后我的方案是分层缓存：短期会话内（5 分钟）命中缓存，超过 5 分钟重新请求。

const nodeCache = new Map() // nodeId -> { timestamp, data } async function getChildrenWithCache(nodeId) { const cached = nodeCache.get(nodeId) if (cached && Date.now() - cached.timestamp < 5 * 60 * 1000) { return cached.data } const { data } = await api.getChildrenById(nodeId) nodeCache.set(nodeId, { timestamp: Date.now(), data }) return data }

这个"新鲜窗口"的设计，可以在"体验流畅"和"数据不过期"之间做一个比较务实的平衡。具体的窗口长度要根据你业务的数据变更频率来定。

4.4 异常兜底：接口失败、数据缺失、超时重试

动态加载还有一个常被忽略的点：异常兜底。一次性全量加载时，如果接口失败，页面至少是完整的，用户还能看到部分内容；但动态加载如果某个节点下钻失败，用户会停留在原地，不知道发生了什么。

我现在的项目里做了三重兜底：

• 请求失败时，节点上显示一个"重试"按钮，点击后重新请求；
• 接口超时（超过 10s）自动 abort，并弹出轻提示说明加载失败；
• 后端返回数据里如果某个节点只有 ID 没有名称等渲染必要字段，前端做好缺省渲染，比如显示"未知节点"，避免整张图崩溃。

function renderNodeFallback(node) { return { ...node, name: node.name || '未知节点', color: node.color || '#999' } }

5. 配套优化：骨架屏、预加载与加载体验设计

动态加载好不好用，最终由用户感知决定。如果你只是"改成异步加载"，但没有任何体验设计，用户会明显感觉到"变卡了"——因为原来是一打开就等待，现在是点击后才等待。所以动态加载必须配套体验层的优化。

5.1 骨架屏替代 Loading 转圈

动态加载的等待通常不会太久（几百毫秒到一两秒），这个区间用转圈 loading 会让用户觉得系统变慢，但不给任何反馈又会觉得"点了没反应"。折中方案是骨架屏——在组件还没加载完成时，渲染一个和最终页面结构相同的灰色占位框。

Vue 里可以用defineAsyncComponent的loadingComponent配合简单的 CSS 骨架：

<template> <div class="graph-skeleton"> <div class="skeleton-node skeleton-node--center"></div> <div class="skeleton-node skeleton-node--left"></div> <div class="skeleton-node skeleton-node--right"></div> </div> </template> <style scoped> .graph-skeleton { width: 100%; height: 500px; background: #f5f5f5; position: relative; } .skeleton-node { position: absolute; width: 80px; height: 80px; border-radius: 50%; background: linear-gradient(90deg, #eee 25%, #ddd 37%, #eee 63%); background-size: 400% 100%; animation: skeleton-loading 1.4s ease infinite; } </style>

这个骨架屏让用户在大脑里预判了"这里即将出现一张图"，比转圈更能降低焦虑感。

5.2 预加载：什么时候提前下载而不是完全按需

动态加载不等于"永远不提前加载"。在某些场景下，预加载能显著提升体验。我总结了一套简单的标准：

• 用户即将触发但尚未触发某个操作时——比如 hover 到按钮上，就预加载组件；
• 用户完成一次操作紧接着大概率会有下一步——比如下钻一个节点后，紧接着大概率会继续下钻子节点。

relation-graph 项目里，我做了这样一件事：下钻某个节点成功后，立刻预请求该节点下所有子节点的"直接子节点数量"，但暂不拉取完整子节点数据。这样用户继续下钻时，接口可以更快响应，因为服务端已经有了部分参数校验和缓存。

async function handleNodeDblClick(node) { // ...原有下钻逻辑 // 预加载子节点的统计信息，为下一步做准备 const children = graphInstance.value.getNodeById(node.id) children?.data?.forEach(async (child) => { if (child.hasChildren && !loadedNodes.has(child.id)) { // 只发轻量预加载请求 preloadNodeChildren(child.id) } }) }

这里要注意，预加载要克制，不能把"下钻一级节点"变成"把整棵树都提前拉完"。我的经验是：预加载只做一级，不要递归预加载更深层级，否则就退化回了全量加载。

5.3 记忆化恢复：切换页面再回来，不要重新加载

动态加载还有一个常见的体验问题：用户下钻了好几层，突然切到别的页面，再切回来，图谱被重新初始化成根节点，之前探索的层级全丢了。

解决方案是保存图谱实例状态，或者至少保存 "当前路径链 + 已加载节点集合"。 relaunch 时如果发现 sessionStorage 里有上次的路径，就自动恢复到对应层级。

// 保存状态到 sessionStorage function saveGraphState() { sessionStorage.setItem('graph-state', JSON.stringify({ currentPath: currentPath.value, loadedNodes: Array.from(loadedNodes) })) } // 恢复状态 function restoreGraphState() { const saved = sessionStorage.getItem('graph-state') if (!saved) return false const { currentPath: savedPath, loadedNodes: savedNodes } = JSON.parse(saved) // 先全量重置到根节点，再逐层下钻恢复 currentPath.value = savedPath savedNodes.forEach((id) => loadedNodes.add(id)) return true }

这个功能做完后，产品经理和用户反馈非常好——大家在上钻下钻探索图谱时，往往有"继续之前思路"的需求，恢复现场能让体验更连贯。

6. 效果数据说明与后续扩展思路

这次动态加载改造完成之后，我特意做了一轮线上数据对比，这里把关键指标列出来，方便你做同类改造时有个预期参照。

6.1 改造前后核心指标对比

这些数据综合起来验证了一件事：动态加载优化后，用户能更快打开页面，操作时也不再卡顿。尤其对低端设备用户，体验提升感知会非常明显。

6.2 可以继续沿用的扩展思路

动态加载这套方法论不局限于关系图谱，以下几种场景同样适用：

• 树形表格：行政区划、组织架构、商品分类，点击展开时动态请求子级数据；
• 无限滚动列表：滚动到底部时请求下一页，而不是一次性渲染全部数据；
• 大图预览 / 地图瓦片：可视区域内的图片先加载，移出视野的图片回收资源；
• 复杂表单：按 Tab 分步加载表单项，而不是打开页面就把所有校验规则和组件都加载完。

核心思路都是同一个：把全量变为增量，把"加载一切"变为"加载用户正在看和即将看的部分"。

提示：动态加载不是一项孤立的技术动作，它需要四层配合——代码分包是地基，路由/组件懒加载负责控制资源加载时机，数据按需拉取负责控制请求体量，而骨架屏、预加载、状态恢复这些体验设计决定用户最终感受到的"是否流畅"。任何一层缺失，最终效果都会打折扣。

最后分享一个我自己的操作体会：做动态加载优化，先不要急着动手改代码，先把当前应用的资源加载时间和数据请求体量量化出来，找到"最重的那一块"——它可能是某个大体积组件库，也可能是一个返回了 800KB 数据的接口。我最初做图谱优化时，第一版只做了组件异步加载，首屏时间降到了 1.8s，但接口返回的 800KB 数据还是让页面卡了几秒。后来把数据层也改成按需拉取，才真正把体验拉满。这个过程告诉我，代码层面的优化和数据层面的优化必须一起做，只优化一层，卡顿感只会转移，不会消失。