绝大多数组件化项目里我们对自己写过的每个模块都很熟悉但用户打开页面那一刻浏览器到底加载了哪些代码、这些代码从哪条链路进来的、重量级模块被多少个路由一起引用——反而常常心里没底。我在给某中后台项目做性能治理时就卡在这一点上构建速度、Chunk数量、打包体积都优化过一轮页面打开却依然是那种说不上快也说不清慢的状态。后来我干脆自己写了一个代号叫rea的解析脚本。rea 是 Resource Entry Analyzer 的缩写当时起名的想法很简单让资源分析回归从入口出发的真相有点认清现实的意思。它做的事情也很直白——从 HTML 入口文件开始沿着所有 script 标签和模块引用关系把每个路由链路里真实加载的 JS、CSS、图片资源全部画出来再做体积归因和重复模块检测。没这个工具之前我以为首屏大概只加载了 1.8MB跑完第一版 rea 才发现实际是 3.4MB有三块大家想当然不需要的代码一直在拖首屏的后腿。这篇文章就是 rea 从一次性排查脚本逐步走到正式工具的全过程。我会把设计思路、AST 依赖提取的实现细节、重复代码检测的朴素算法、以及我在真实项目里用 rea 挖出来的几类典型问题都讲清楚。适合手头有中大型前端项目、也想把资源治理真正落到数据层面的朋友参考。1. 为什么我要自己写一个 rea而不是直接用现成的构建分析工具1.1 现成工具的三个说不清先说结论不是现成工具不好而是它们回答的都不是链路问题。拿我们最常用的打包体积分析工具来说它确实能列出某个 Chunk 有多大、包含哪些模块但它展示的是构建产物的世界——产物被拆成多少块、每块多大、依赖关系如何。可用户在浏览器里经历的是一条时间线先拿到 HTML再解析 script触发模块请求进入首屏渲染接着滚动页面触发懒加载。构建产物和运行时链路之间隔着一层入口逻辑和路由分发。监控面板类的指标平台则是另一个极端。它们给的通常是总请求数、平均耗时、白屏率这种聚合数据能告诉你这个页面整体慢了却没法告诉你是哪个模块的 import 语句把 600KB 的图表库拖进了首屏。这种信息差在大型项目里非常致命你得到一份首页 JS 体积偏大的报告但打开报告只能看到十几个体积数字没有一条从 HTML 到具体模块的完整引用链条排查看起来就像拆线头。Lighthouse 类工具就更偏结论导向了。它跑完给出性能分数列出减少未使用的 JavaScript这类建议但同样没有回答这段未使用的 JS 是从哪个路由入口进的、是哪个公共组件带进来的、可不可以延迟到下一个交互节点。三次优化之后我就意识到缺的根本不是有没有问题的结论而是问题资源在依赖图里处于什么位置、被谁引用、该从哪条链路上拆的定位能力。1.2 我让 rea 必须回答的三个具体问题所以我在写 rea 之前先给自己定了三个必须回答的问题这几个问题直接决定了后面所有数据结构设计首屏成本用户从拿到 HTML 到完成首次可交互期间一共消费了多少 KB 的 JavaScript、CSS、图片这个数字拆到每个模块头上是多少重复归属哪些模块被多个路由链路重复引用重复引用的代价到底有多大尤其是体积超过 100KB 的模块被 10 个页面重复拉取时浪费是实打实的。可延后性哪些模块本可以在下一个关键节点比如点击某个按钮之后、滚动到某个区域之后再异步加载现在却被同步逻辑带进了首屏这三个问题有一个共同点它们都依赖从入口到模块的路径数据。现成工具要么没有路径信息要么把路径信息藏在 Arc 图里让人肉眼看。与其等它出新功能不如我自己写一个能输出结构化路径数据的小工具后面不管做报告还是接告警都方便。1.3 验证目标一个 150 路由的中后台项目rea 最初的目标项目是某中后台系统150 多个路由、300 多个页面级组件、几十个公共组件和工具库历史原因导致的什么都在全局引问题很严重。这个体量特别适合做链路分析因为路由之间共享了大量公共代码任何一个包体积上浮都会被放大成几十个页面的共同负担。我当时的验证目标很简单先跑出一份首页 列表页 详情页三条典型链路的资源清单看看能不能靠这份清单找到至少一个可以立竿见影的优化点。如果做不到说明工具在数据维度上还有缺漏做到了再往 CI 和自动化方向发展。后来第一版跑出来半小时内就找到了那 580KB 的图表库问题这给了我继续深挖的信心。2. rea 的核心设计从入口出发的运行时资源依赖图2.1 为什么必须从入口出发而不能直接分析打包产物我一开始也试过直接在产物上做文章把 webpack 输出的 assets 列表按大小排序再手动关联页面。但只弄了半小时就放弃了因为产物和页面之间是多对多关系——一个路由用的代码可能散落在十几个异步 Chunk 里一个公共 Chunk 又被十几个路由同时使用光靠文件名猜关联效率太低准确性也不够。rea 的核心选择是从入口文件出发完全模拟浏览器的执行顺序拿到 HTML 里的 script 和 link 标签把同步加载的模块先建起来遇到动态 import 再按运行时行为把异步分支接上。这样做的好处是最终产生的依赖图天然带着哪条链路、什么时机、多大代价的语义。就好比你想知道一条河的水量不能只看所有支流的统计表得从源头沿着河道走一遍才能知道哪些水真的流到了入海口。2.2 数据采集三路输入互为补充rea 的数据有三个来源缺一不可入口 HTML 文件从构建目录里找到每个路由对应的 HTML解析其中的 script、link、img 等标签。这部分决定了这条路由最初触发了哪些资源请求。构建中间产物 stats.json我要求构建时额外输出一份统计文件webpack 的--json参数就能生成。rea 从这里拿到模块 ID、模块路径、Chunk 归属、module 与 module 之间的依赖关系。静态分析阶段主要靠它。运行时 performance 资源列表在很多项目里静态分析会遇到动态拼路径、运行时才生成的模块名这类模块在构建产物里未必有显式引用关系。rea 会从已上线的页面里采集performance.getEntriesByType(resource)把真实发出的请求补进依赖图标记为运行时观测节点。第三路数据看着有点绕但在后面处理动态 import 变量化问题时它是唯一的救命稻草。后面踩坑部分我会单独讲。2.3 依赖图构建流程核心四步走rea 的构建流程分成四个步骤每一步都对应一种链路信息的补全第一步解析 HTML 入口。把每个路由的 HTML 文件读进来用解析器提取同步 script 和 link 标签、内联 script、以及静态图片引用。这一步产出依赖图的根节点和第一批子节点。根节点就是 HTML 文件本身子节点是它直接声明的资源。第二步递归解析模块引用。从第一批 JS 节点出发用 AST 提取它们内部的import、require、import()语句找到被引用的模块 ID再顺着这些 ID 继续往下递归。这里要特别注意处理路径别名否则遇到/views/home/index.vue这种写法就直接断链了。我在这步会加载项目的 webpack 配置里的 resolve.alias把别名统一转换成绝对路径再做匹配。第三步识别路由级代码分割点。中后台项目几乎都用了动态路由或按需加载组件静态分析里这些地方表现为import()表达式。rea 会把动态 import 的模块单独标记为异步节点并记录它挂在哪个父节点下面。这一步区分了首屏同步链路和后续行为链路是后续体积归因的基础。第四步节点合并与统计。同一模块可能从多条链路被引用到rea 会把重复出现的节点标记为多次引用并记录引用它的父节点列表。然后自底向上累加体积算出每个节点如果被同步加载会向父链路传导多少字节。2.4 数据结构为了让机器能读JSON 是标配rea 内部把整个依赖图输出成一份推荐 JSON。核心结构大概长这样{ entries: [ { route: /dashboard, entryFile: dist/views/dashboard/index.html, syncChain: [ { id: chunk://runtime, size: 18432, depth: 1, refs: [chunk://vendors~react], from: html-script }, { id: module://src/components/LargeChartPro.tsx, size: 152602, depth: 4, refs: [module://node_modules/echarts/echarts.min.js], from: static-import } ], asyncChain: [ { id: module://src/views/order/ExportExcel.tsx, size: 321084, depth: 2, refs: [module://node_modules/xlsx/xlsx.full.min.js], from: dynamic-import } ], totalSyncSize: 1122334, totalAsyncSize: 468900 } ], duplicatedModules: [], generatedAt: 2024-03-15T10:00:00Z }这份 JSON 既是 rea 的最终产物也是后续所有分析的中间输入。要生成 Markdown 报告就解析它要做版本对比就 diff 它要接 CI 评论就把它塞进模板里。数据结构定了之后后面所有功能都是围绕它转的。3. 关键实现细节AST 解析、重复代码检测和体积归因3.1 为什么依赖提取必须用 AST而不是正则匹配可能有人会想提取 import 语句不是用正则匹配字符串就行了吗我最初的原型版本确实用了正则比如匹配import xxx from xxx和require(xxx)但在真实项目里很快就被打脸了。原因有三种第一种是注释和字符串干扰。代码里经常有被注释掉的整段 import或者import.meta.url这种路径字符串正则一不小心就会把它们当成真实依赖。第二种是动态写法。很多模块引用是import(/views/${folderName}/index.vue)或者是require(config.componentPath)这种模板字符串硬用正则去抠抠出来的是一堆残缺路径根本没法解析。第三种是别名和扩展名处理。正则拿到的路径还停留在/utils/format没有经过 webpack 的 rules后续去磁盘找文件会非常痛苦。所以我后来改用 AST 解析器我在 Node 环境用的解析器组合是 acorn 配 acorn-jsx处理 TypeScript 和 Vue 单文件时引入了对应的解析插件把 JavaScript 代码解析成完整的语法树再遍历节点做精准提取。AST 方式的好处是我只关心语法树上的 import 节点注释、字符串、函数体内无害文本天然被过滤掉。3.2 依赖提取的实现伪码这里给一段我实际使用的核心伪码展示依赖提取的骨架。不同项目的解析器版本不同但思路是通用的const acorn require(acorn); function extractDependencies(source, filePath) { const ast acorn.parse(source, { sourceType: module, ecmaVersion: 2022, locations: true }); const deps { static: [], // import A from B require: [], // const A require(B) dynamic: [] // import(B) / import(expr) }; const walk (node) { switch (node.type) { case ImportDeclaration: deps.static.push(node.source.value); break; case VariableDeclarator: if (node.init node.init.type CallExpression node.init.callee.name require) { const arg node.init.arguments[0]; if (arg arg.type Literal) deps.require.push(arg.value); } break; case ImportExpression: // 动态 importarg 可能是 Literal也可能是 TemplateLiteral if (node.source.type Literal) deps.dynamic.push(node.source.value); else deps.dynamic.push(runtime:${node.source.start}); break; } for (const key of Object.keys(node)) { if (key type) continue; const child node[key]; if (Array.isArray(child)) child.forEach(walk); else if (child child.type) walk(child); } }; walk(ast); return resolveAliasesAndExtensions(filePath, deps); }遍历的时候注意要递归处理所有子节点有些同学只遍历了 body 数组结果漏掉函数内部定义的 require导致依赖图缺了很大一块。resolveAliasesAndExtensions 这一步我会结合 webpack 的 resolve.alias 和 resolve.extensions 配置把/views/home解析成具体文件路径再判断它是 .ts、.tsx、.js 还是 .vue保证递归时能正确读文件。3.3 重复代码检测朴素算法加两轮指纹去重重复代码是资源治理里最容易被忽略的隐性成本。rea 做得比较朴素分两轮第一轮直接看构建产物的公共 Chunk。如果同一个模块以 resolved 后的绝对路径为 key出现在多个 Chunk 的 modules 列表里就说明它被多份代码副本携带。这个用构建统计文件就能算出来准确性高。第二轮看内容指纹。有些包同名不同版本比如项目里某个旧库的依赖锁死了 lodash 4.17另一个新库又引了同样的 lodash 版本但由于打包器的反复分层产生了两个不同大小的副本。rea 会对体积大于 50KB 的模块计算内容哈希哈希一致但路径不同的模块标记为同内容副本。这种检测成本很高所以我只在报告的最末位展示不默认全量开启。重复模块检测属于慢但有用的功能一次全量扫描可能要多花一两分钟但能直接指出你项目里有两个 echarts 副本其中一个是被某个老组件带上来的。这类问题靠人眼翻产物列表是几乎不可能发现的。3.4 体积归因从Chunk 体积上升到链路成本体积归因是 rea 最有价值的部分也是最容易被低估的部分。常规工具做的是每个 Chunk 多大rea 做的是每个叶子模块的价值等于自身体积加它向所有上游链路传导的体积。算法很简单从入口节点出发沿依赖边做深度优先遍历每个节点对当前链路的贡献等于它的同步大小多次被不同链路引用时按每条链路的实际路径分别统计不简单合并。这样做之后输出就不是voyager 页面里 echarts 占 600KB这种模糊描述而是首页链路中LargeChartPro.tsx 自身 152KB它直接引用的 echarts.min.js 重 580KB这条链路整体为首页贡献了 732KB 同步成本。看到这个数字你会立刻明白该拆谁、从哪里拆。我给每个入口算几个关键指标同步链路总大小、同步节点数、异步链路总大小、链路上体积前五的节点。这些指标直接进报告顶部方便快速定位大胖子。3.5 报告输出JSON、Markdown 和 SVG 三种形态rea 本身不追求好看的可视化但报告必须让团队看得懂、用得起来。我做了三种输出JSON完整依赖图给机器和后续 diff 用。Markdown 报告每个路由一节列体积 Top 10 的节点和重复模块适合贴在 MR 描述里人工审阅。SVG 火焰图最轻量的可视化方案。我把链路渲染成横向的火焰图宽度对应该节点的体积贡献鼠标悬停展示路径信息。只做了纯前端生成没引入重型图表库因为可视化只是辅助真正决策还是要看数字。这三种输出共用了同一份 JSON 数据等于一次计算三种消费。这个设计让我后来接 CI 和做版本对比时几乎没改过核心逻辑。4. 在真实项目里的排查实战与优化效果4.1 第一次跑出结果三个隐性炸弹浮出水面rea 在目标项目里跑出的第一份报告直接刷新了我们对首屏成本的认识。之前估算的首页 JS 成本是 1.8MB看报告才发现真实同步链路是 3.4MB其中一大半来自三个我们从未怀疑过的模块模块路径自身体积主要依赖被多少个入口同步引用src/components/LargeChartPro.tsx152KBecharts.min.js 580KB12src/directives/preventDoubleClick.ts2KBdayjs 全量 68KB但被 40 个页面同步引用40src/layouts/BasicLayout/HeaderUserInfo.tsx88KB某基础业务包 210KB全部后台布局第一颗炸弹是图表库。12 个路由的模板在顶层直接引用了公共图表组件而这个组件同步引用了 echarts 全量包。输入路径归因后首页的同步体积凭空多出 580KB 的图表库可首页本身连一个图表都没有。第二颗炸弹是 date 工具的滥用。项目里大量页面组件引用了统一封装的时间处理工具它内部 import 了完整 dayjs 库。dayjs 单包体积不算大但当 40 个入口都把它放在同步链路上因为它被设计成对外暴露全部方法打包器很难摇树整体浪费就很可观了。第三颗炸弹是布局组件的反向依赖。HeaderUserInfo 这个组件只是头像和用户菜单但它的实现里直接引了整个基础业务包导致所有后台页面只要加载布局就必然把这块 210KB 的依赖拖进首屏。4.2 案例一图表库被 12 个路由同步引用这是 rea 帮助定位的第一个完整优化案例。通过链路上游归因我看到首页大量入口路径都指向同一个引用layout/components/LargeChartPro.tsx里的import * as echarts from echarts。这个组件本身是个方便套壳的公共组件——提供基础配置、自动 resize、暗黑主题切换结果背书了最重的依赖。修复方案不复杂把 LargeChartPro 改为懒加载组件仅在实际传入 chartOption 数据时动态引入 echarts同时把 echarts 的引入方式从import * as echarts from echarts改成按需引入核心模块和需要的图表类型再把不传 chart 数据的普通页面改为完全不渲染该组件。效果立竿见影首页同步链路减少约 580KB列表页、详情页也同步受益。更重要的是12 个页面里真正用图表的只有 3 个另外 9 个页面本来就只是引了个空壳组件。4.3 案例二动态 import 里的隐性重包第二个案例更有意思。它是 rea 识别出的一个异步重节点模块路径是src/views/order/ExportExcel.tsx。这个模块在点击导出按钮时才动态 import表面看不影响首屏。但 rea 的依赖图显示这个模块内部通过import orderUtils from ../../utils/order引入了一整套业务工具这个工具 arr 里又引了完整 xlsx 库和一个财务计算函数库整链异步体积 321KB。问题不在于它被异步加载而在于导出延迟。用户点击导出后浏览器要在下载完 321KB 代码后才开始执行逻辑中低端手机上体感是白屏接近两秒。rea 把这个节点标注为async_heavy之后我们把它拆成两层第一层只动态引入纯函数的 Excel 生成逻辑第二层把大体积的 xlsx 库放到用户点完导出、正式构建文件时再请求。结果导出点击到弹出下载文件的耗时从 2.1 秒降到 0.7 秒。这个案例说明异步节点不等于安全节点。异步只是把成本从首屏挪到了交互时刻如果交互模块质量太差用户照样感知明显。rea 的价值就是把这种隐性迁移成本量化出来。4.4 优化前后的核心数据对比整个优化周期约两周基于 rea 报告逐条处理最终数据如下指标优化前优化后降幅首页同步 JS 体积3.4MB1.2MB64.7%首页同步请求数873658.6%DOMContentLoaded中位数2.8s1.9s32.1%列表页同步体积2.1MB0.9MB57.1%导出点击到文件下载2.1s0.7s66.7%这些数字不是卷出来的是切切实实把链路里的大节点拔掉之后自然呈现的结果。团队成员对 rea 的态度也在这段时间从这脚本到底靠不靠谱变成发版前赶紧跑一遍。4.5 持续回归检测把 rea 从优化工具变成护城河优化做完之后rea 并没有退役。性能问题和水位一样会慢慢回升——新同学可能随手又引了一个全量组件库或者一个看似轻巧的公共函数把体积炸弹带进了路由。所以我在 rea 之外加了一个 diff 模式每次跑完全量分析保存 report.json下次再跑用脚本对比两份报告的入口大小、Top 体积节点、重复模块数量。任何新增同步体积超过 20KB的变更都会被打进日志提醒。在接入 CI 之前我先在本地跑了一周的回归测试确保 diff 脚本不会因为构建抖动产生海量无效报警。阈值调稳后才放心往外推。事实证明这个积累非常值得上线第 10 天就抓到一个列表页新增同步引用 260KB 的回归变更及时在 MR 阶段拦了下来。5. 踩过的坑跨包引用、动态导入和缓存带来的干扰5.1 坑一monorepo 内路径别名让依赖图断链rea 早期跑某子应用时出现过依赖图断头问题所有的入口都有但往下追踪到一半某个模块就显示不出来后面的节点全部丢失。排查发现原因是子应用里大量使用了 monorepo 的包别名——import { Button } from company/ui这类包还通过 lerna/symlink 挂到了 node_modules 之外。rea 默认只在项目根目录下找文件company/ui解析后指向的路径根本不在扫描范围内。解决方式是在 resolver 配置里额外收集 pnpm workspace 的.pnpm目录和 monorepo 的packages/*软链接地址把它们加入可解析路径列表。改完后再跑依赖图终于完整了我也顺手把解析失败的节点数量作为报告里的一项质量指标只要大于 0 就提示依赖图不完整请检查配置。5.2 坑二动态 import 变量化让静态分析失明这是最让我头疼的坑。项目中有一部分页面采用了路由级目录约定import(\/views/${dirname}/index.vue)。AST 解析器看到 TemplateLiteral没法从语法树直接拿到真实路径。rea 早期对这些节点只是简单标记结果依赖图在路由层直接缺了一大片。最终解法是双轨制静态分析阶段把这类模板字符串标记为运行时节点再启动一个轻量的无头浏览器脚本真实访问几个代表页面通过performance.getEntriesByType(resource)拿到实际加载的 JS 文件名反向映射回模块路径把这些观测结果补进依赖图。耗时从纯静态的 40 秒增长到 85 秒但换来的是完整链路值。5.3 坑三浏览器缓存让 performance 数据严重偏低如果直接拿运行时资源列表当体积依据会踩一个大坑缓存命中。用户二次访问页面时大量 JS 是从 memory cache/disk cache 里读的performance.getEntriesByType(resource)里的 transferSize 可能为 0 或极小。如果 rea 用这个数据算首屏成本结果会比真实冷启动偏低一半以上。我的做法是只把运行时数据用于补链路关系不用于体积统计。体积一律以构建产物文件在磁盘上的实际字节数为准这样无论缓存策略怎么变数据口径都保持稳定。类似首屏成本这种指标也必须说明是冷启动视角。5.4 坑四CSS 里的 import 和字体、背景图漏算JS 依赖图补齐后我一度以为链路完整了直到有一次对比发现 rea 报告的字节数比浏览器 Network 面板少了不少。逐一检查后才意识到CSS 的import链、url()里引用的字体文件和背景图都没进依赖图。修复方法是用 CSS 解析器我用的是 postcss 的 parser遍历所有样式文件提取import和url()引用再把它们作为样式节点接入依赖图并区分同步 CSS 和异步 CSS。这一改之后入口成本里多了约 160KB 的字体文件——恰好就是之前缺失的那部分。现在 rea 报告里会单独标出样式资源总览。5.5 踩坑经验汇总问题类型典型表现影响规避方法路径别名解析依赖图中途断链链路数据不完整复用构建配置的 resolve.alias额外收集 workspace 路径动态模板字符串AST 无法还原路径路由级节点缺失静态标记 运行时资源表反向补充浏览器缓存transferSize 为 0体积统计失真体积口径用磁盘文件大小不用运行时 transferSizeCSS 资源引用字体/背景图漏算成本低估用 CSS AST 提取 import 与 url()6. 后续扩展把 rea 接进 CI、输出团队可读的回归报告6.1 每次 MR 自动跑评论区贴出资源衰减对比当 rea 本地模式和 diff 模式稳定之后下一步自然是接进 CI。我在流水线里加了一个资源体检阶段拉取目标分支代码、安装依赖、执行生产构建并输出 stats.json然后跑 rea 全量分析再用脚本对比目标分支与合并基准分支的 report.json生成一段压缩版对比表。对比表我会控制信息密度只输出三类变化入口同步体积变化 Top 5新增的同步引用节点尤其是大于 50KB 的重复模块数量变化。这段对比表通过流水线的评论功能直接贴到 MR 下评审人不需要懂 rea 也能看到此次改动让首页同步体积增加 220KB这类关键信息。6.2 预算告警阈值设置与误伤规避接 CI 时最容易被团队吐槽的是误报。一开始我把阈值设得很严任何入口同步体积增加超过 10KB 就告警。结果第三天就炸了——一个需求正常新增了两个图表同步体积增加 45KB但这是业务必须的。告警之后还得人工解释反而消耗信任。后来我把策略改为两级阈值第一级是黄色提醒单入口同步体积超过历史基线 5% 或新增同步体积超过 50KB第二级是红色拦截单入口同步体积超过绝对预算比如 800KB或新增体积超过 100KB。同时支持在配置文件里按路由加白名单比如营销活动页面允许首屏体积临时上浮 20%。这套机制跑了一个月团队成员普遍认可因为它不再是提醒你变胖而是替你守住底线。6.3 可视化选型的教训先说清楚给谁看我最早想把 rea 做成美观的可视化大屏结果在瀑布图和火焰图之间反复横跳浪费了不少时间。后来想明白一件事可视化先得说清楚给谁看。给开发人员看的定位图核心是能悬停查看路径、能点击展开依赖给管理者看的报告核心是趋势数字和涨跌箭头给我自己看的调试视图甚至可以用最丑陋的文本树。想通之后我只保留了两样SVG 火焰图给开发排查和 Markdown 数字报告给 MR 评审。项目里没有引入任何额外的重量级前端图表库全靠基础 SVG 拼接维护成本很低。6.4 还可以继续扩展的方向rea 到目前这个程度已经够用但确实还能继续长把历史 report.json 落库做入口体积趋势曲线接入通知机器人红色告警直接推群把重复检测从体积大于 50KB 放开到所有公共模块做更精细的依赖治理。这些方向不是必须只是在有余力时值得考虑。我在实际使用中最深的一点体会是工具的价值不是替代经验判断而是让判断基于完整事实。以前做性能优化靠猜、靠听说、靠这个包好像挺重要现在每次决策都有 rea 的路径数据兜底。另一个很值得养成的习惯是每次重构完任何公共组件或工具函数都顺手跑一遍当前主入口的 rea 报告指标没有异常再合代码。一次扫描不到两分钟但能省掉很多上线后被用户反馈卡顿的回头路。