HTML模板不直接产生“组件占比”，该指标实为构建工具分析的模块体积占比；模板写法影响依赖引入路径与组件拆分粒度，进而决定最终打包体积分布和渲染性能。
HTML 模板本身不直接产生“组件占比”指标，但你在构建页面时选择的布局方式（比如 table、flex、grid 或框架级组件结构）会显著影响最终打包产物中各模块的体积分布和渲染性能表现。所谓“组件占比”，实际是构建工具（如 Webpack/Vite）分析输出的模块体积占比，不是 HTML 原生概念。
为什么 HTML 模板会影响组件体积占比
模板写法决定依赖引入路径和组件拆分粒度：
- 用
<el-row>这类 UI 框架组件，会把整个 Element Plus 库或按需引入的子模块打包进来——哪怕只用了一个布局容器，也可能拖入大量未使用的样式和逻辑 - 手写
display: flex的<div>布局，零额外 JS 依赖，体积占比几乎为 0，但牺牲了语义化与跨框架复用能力 - Vue 单文件组件中
<template>内嵌套过深（如多层<div class="wrapper"><div class="table_con">...），会导致编译后生成冗余 DOM 节点，增加内存占用和首屏解析时间
如何在 stats.html 中识别模板相关组件的体积占比
运行 npm run build -- --report（Vite）或 webpack --stats 后打开 stats.html，重点关注：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 搜索关键词：
node_modules/element-plus或components/RatioAnalyse.vue—— 如果你用了自定义组件名，它会以文件路径形式出现在模块列表里 - 查看
ratio-analyse.js或类似 chunk 的大小：如果单个组件 JS + 模板编译后超过 50KB，大概率存在未剥离的样式、图标或冗余import - 对比
vendor和chunks标签页：若el-row相关代码出现在 vendor 中，说明它是全量引入；若在某个异步 chunk 里，则可能是按需加载配置生效了
避免模板写法拉高体积占比的实操建议
不改设计的前提下压缩模板带来的体积开销：
立即学习“前端免费学习笔记（深入）”；
- 把
<el-row style="display: flex">改成原生<div class="flex-row">，并在 CSS 中统一管理.flex-row { display: flex; }—— 省掉框架布局组件的 JS 解析开销 - 删掉无意义的 wrapper 层：
<div id="wrapper" class="wrapper flex-center-stretch flex-column">中的id和多余 class 若未被 JS 或样式引用，就直接移除 -
.table_con { width: 49%; }这类固定百分比，在响应式场景下容易触发重排；改用flex: 1+gap: 2%更轻量且兼容性更好 - 如果项目已用 Vite，检查
vite.config.ts是否启用了build.rollupOptions.external把 Element Plus 外链 CDN —— 这样它的体积就不会计入你的打包报告
真正影响性能的是模板背后加载的代码，而不是标签本身。一个空 <div> 和一个 <el-row> 在 HTML 字节上差不了多少，但在 JS bundle 里可能差几百 KB。别盯着 class 名优化，要去 stats.html 里看真实 chunk 构成。
