Vue 3性能优化需兼顾渲染与体积：用rollup-plugin-visualizer分析Gzip后组件体积，超100KB需检查按需引入是否生效、是否存在未拆分重型依赖或隐藏体积大户（如自定义指令），并结合Vue Devtools定位Mount/Update瓶颈。
组件渲染性能和打包体积是两个维度的问题，但它们在实际体验中紧密关联：一个体积过大的组件，往往意味着更多 JS 解析、更长的挂载时间、更高的内存开销，进而拖慢首屏渲染和交互响应。Vue 3 中要真正看清“哪个组件拖慢了渲染”，不能只看运行时 profile，必须结合打包工具分析它在构建产物里占了多少空间。
用 visualizer 看清组件真实体积
Vite 项目推荐直接接入 rollup-plugin-visualizer，它能生成交互式 treemap 图，把每个 .vue 文件编译后的 chunk 显式标出大小：
- 安装后配置
visualizer({ open: true, gzipSize: true })，构建完成自动打开 HTML 报告 - 报告中搜索
.vue关键字，就能定位到具体组件文件（如Dashboard.vue对应的 chunk） - 重点关注 Gzip Size 列——这才是用户真实下载量，比原始体积更有参考价值
- 若某个组件 chunk 超过 100KB gzip，大概率存在过度依赖或未拆分逻辑（比如内嵌了完整 ECharts 或富文本编辑器）
识别“假轻量”组件：按需引入没生效
很多 UI 组件库（如 Element Plus、Arco Design）宣称支持按需，但实际体积没降下来，往往因为：
vue-component-analyzer
下载
递归分析 Vue 项目组件依赖，从入口文件生成组件层级图，支持 Vue 2/3，输出组件名、文件路径和属性。适用于分析组件结构、排查依赖或了解项目架构。
- 用了
import { ElTable } from 'element-plus'却没配 unplugin-vue-components，样式和依赖未自动导入，导致构建器 fallback 到全量包 - 组件内部静态 import 了重型模块（例如某封装好的
UploadEditor.vue直接import * as quill），Tree-shaking 失效 - 在
setup()里动态 import 了大模块，但没做 loading 状态兜底，造成白屏感被误判为“渲染慢”
把体积数据映射到渲染链路
单纯知道“组件 A 是 85KB”还不够，要结合 Vue Devtools 的 Performance 面板交叉验证：
立即学习“前端免费学习笔记（深入）”；
- 录制一次首屏加载，在 Components 标签页找到该组件，点开查看 Mount time 和 Update time
- 若 Mount 时间长 + 打包体积大 → 优先优化依赖（比如用
date-fns替moment，或把图表抽成异步子组件） - 若 Mount 时间短但 Update 频繁 → 问题不在体积，在响应式设计（比如监听了整个大型对象，或 computed 里做了深拷贝）
- 把 visualizer 报告里的“高体积组件”列出来，逐个检查是否真的需要在首屏同步加载；能
defineAsyncComponent的就拆出去
警惕“隐藏体积大户”：插件与指令封装
容易被忽略的是自定义指令（v-permission）、全局 mixin 或 composables 封装的逻辑：
- 一个
usePermission.ts若内部引用了lodash全量方法，会把整个lodash打进所有用到它的组件 chunk - 全局注册的指令如果依赖复杂校验逻辑，也会随每个使用它的组件重复打包
- 在 visualizer 报告中搜索
use或directive，看对应 chunk 是否异常偏大 - 解决方案：把 heavy logic 提取为独立的异步 hook，或改用轻量替代（如
lodash-es+ 显式导入）
