webpack bundle analyzer 不分析 html 模板——因其仅处理 webpack 打包产物（js/css/json/wasm），而 index.html 作为静态模板不参与模块依赖图构建，stats.json 中也不包含其内容或硬编码引用。
Webpack Bundle Analyzer 不能分析 HTML 模板本身的体积或引用关系——它只处理 Webpack 打包产物（即 JS、CSS、JSON、WASM 等模块化资源），而 index.html 这类静态模板文件默认不被 Webpack 加入依赖图，也不会出现在分析报告中。
为什么 HTML 文件不会出现在 Bundle Analyzer 报告里
Webpack 的核心工作流是“模块化打包”：它从入口 JS 文件出发，通过 import/require 递归解析依赖，最终生成 bundle。HTML 文件通常由 html-webpack-plugin 注入 script 标签，但本身不是模块，不参与依赖图构建。即使你用 template: './src/index.html'，插件也只是把 HTML 当作字符串渲染，不解析其中的 <script></script> 或 <link> 标签为模块依赖。
- Bundle Analyzer 的输入是 Webpack 的
stats.json，而该文件不含原始 HTML 内容或其引用的外部资源（如 CDN 链接、内联脚本） -
<script src="xxx.js"></script>这类硬编码引用，Webpack 完全感知不到，自然不会统计 - 即使你用
html-webpack-plugin的chunks选项控制注入，Analyzer 也只看到 JS chunk 的大小，看不到 HTML 如何组织这些 chunk
想查 HTML 引用了哪些资源？得换工具或手动检查
如果你真正关心的是 HTML 模板实际加载了什么（比如误加了重复的 CDN、内联了大段未压缩 JS、引用了未使用的字体文件），Bundle Analyzer 帮不上忙。可行做法是：
- 直接打开生成的
dist/index.html，肉眼检查所有<script></script>、<link rel="stylesheet">、<link rel="preload">标签 - 用浏览器 DevTools 的 Network 面板，清空缓存后刷新页面，看哪些资源被真实请求、大小多少、是否 404 或重复加载
- 用
html-validate或自定义脚本扫描 HTML 中的src/href属性，比对项目中实际存在的文件路径 - 如果 HTML 是由服务端模板（如 EJS、Pug）生成的，需在构建前检查模板逻辑，而非依赖 Webpack 分析
Bundle Analyzer 能间接帮你优化 HTML 相关行为的地方
虽然它不看 HTML，但它能暴露 HTML “背后”真正被打包进 JS/CSS 的内容，这些内容往往决定了 HTML 的加载效率：
- 发现某个
vendor.js里混进了本该由 HTML 直接引入的第三方库（比如你本想用 CDN 引入lodash，却在 JS 里又import _ from 'lodash'），这时删掉 JS 里的 import，再确保 HTML 的 CDN 链接正确，就能减小 bundle 体积 - 看到
app.js里包含大量内联 SVG 或 Base64 图片字符串，说明 loader 配置（如url-loader的limit）可能设得太低，导致小资源被转成代码而非独立文件——调整后，HTML 可以更干净地引用这些独立资源 - 发现
styles.css体积异常大，点开看发现含了整套bootstrap.css，而你其实只用了两个 class——这时应改用按需引入（如@import '~bootstrap/scss/buttons'）或替换为轻量方案，HTML 中的<link>就能指向更小的 CSS
真正容易被忽略的点是：很多人盯着 Analyzer 报告猛点“最大的矩形”，却忘了检查这些模块是否本不该被打包——比如本该走 CDN 的库、本该放 public 目录的静态资源、本该用动态 import() 懒加载的路由组件。优化 HTML 加载体验，关键不在 HTML 文件本身，而在它所触发的资源加载链路是否精简、合理。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
