函数层依赖包体积过大，会在启动阶段被逐个解析、编译和实例化，直接拉长首屏可交互时间，这也正是函数层依赖拖慢启动的根源所在。
函数层依赖包体积，到底卡在哪里
函数层的依赖不像普通模块那样按文件加载，它藏在闭包里，一个函数在定义时引用了外层变量、兄弟函数、公共工具库里的某个纯函数，打包器会把这些引用关系形成一张闭包网，启动时，JavaScript引擎要完成词法解析、语法树构建、字节码生成，遇到闭包还得捕获环境记录，每一步都要为“可能存在”的调用预留位置。
多数情况下，函数级依赖的体积并不大，单看每个包裹只有几百字节，可一旦入口文件依赖了某个组件库，组件库内部又按函数粒度互相引用，打包后的模块图就会异常复杂，运行时的表现就是：页面还没渲染，浏览器先花了几百毫秒解析一个巨大且几乎全是“死代码”的闭包集合。
这里有个容易混淆的概念，和传统的模块级依赖相比，函数级依赖更隐蔽，也更容易被忽略，老牌优化工具能很好地处理文件级tree shaking，却在函数内部互相调用的场景里显得吃力，说白了，一个模块里可能有几十个函数，只有两三个被真正用到，但整段代码都要被解析,这就是函数层依赖的控制力所在。
为什么传统的按需加载救不了你
按需加载的粒度通常是“模块”或“路由组件”，比如路由懒加载，用户访问A页面时才拉A页面的chunk，可如果A页面内部的工具函数依赖了B模块的某段逻辑，这段逻辑会被打进A页面的chunk里,随着A页面的加载一起执行。
此时启动速度受影响的程度取决于函数依赖链的长度，链越长，脚本评估时间越长，业内专家指出，一个由几十个函数闭包组成的依赖链，在低端安卓机上的解析时间可能是高端设备的3倍左右,而这种差距几乎全部发生在启动阶段。
webpack打包优化从哪入手：先分清函数级依赖和模块级依赖
要解决拖慢启动的问题，得先搞清楚东西放哪里，函数级依赖和模块级依赖的区别决定了你该用哪种工具去处理,下表整理了常见维度上的差异：
| 对比维度 | 函数级依赖 | 模块级依赖 |
|---|---|---|
| 依赖粒度 | 单个函数及其闭包引用 | 整个文件或整个导出块 |
| 检测难度 | 需要静态分析函数调用关系 | 只需分析import/export语句 |
| 常见产生方式 | 内部工具函数互相调用，出口文件集中导出 | 组件库整体引入，命名空间导入 |
| 对启动的影响 | 解析阶段耗时长，闭包捕获次数多 | 编译阶段耗时长，全量转为字节码 |
| 优化手段 | 函数级tree shaking、pure标记 | 按需导入、模块重导出精简 |
拿webpack举例，函数级依赖和模块级依赖区别的影响在sideEffects配置上体现得最直接，你把某个包的sideEffects标记为false，webpack会认为这个包里的所有代码都没有副作用，可以从任何未被引用的导出中移除，但前提是移除的粒度真的能达到“函数”一级。
实践里常见的坑是：工具包导出一个对象，对象里放了十几方法，每个方法单独实现但共享内部helper，标记sideEffects: false后，未被引用的方法会被删，可被引用的方法依赖的helper却因为“引用关系发生在函数内部”而不能被正确识别，于是所有helper全部保留,函数层依赖当场膨胀。
实操：先在bundle分析图里找到肉瘤
建议按下面几步定位问题,这也是多数优化项目的标准动作：
- 用
webpack-bundle-analyzer生成gzip前的模块依赖可视化图谱。 - 切换到“concatenated module”视图,找到体积最大但实际导出利用率低的模块。
- 点击进入模块内部,看内部函数是否形成了互相引用的密集图。
- 对比入口加载路径里,哪些函数实际上从未在业务代码中收到过调用。
如果图谱里满是小方块像是一串葡萄，说明函数引用关系非常集中，这时候再检查代码,大概率能看到这样一段：
// utils/index.js
export const a = () => { return c(); };
export const b = () => { return c(); };
export const c = () => { / 复杂逻辑 / };
业务里只用a，但a又依赖c，b看似没被引用，可b和a同一模块，解析时依旧会把b的函数声明提升并处理，要解决，就得把c抽成单文件再分别导入。
启动阶段的三段式拖慢链路：解析、编译、执行
函数层依赖包体积对启动的伤害不是瞬间发生的，它会经历三个阶段,层层累积。
- 解析阶段：引擎读取源码，将字符串转为AST，函数越多，AST节点越多,这个阶段的时间与函数声明数量直接正相关。
- 编译阶段：AST转为字节码，需要为每个函数分配作用域上下文，闭包引用越多，作用域链就越深,编译耗时跟着涨。
- 执行阶段：顶层代码执行时，遇到函数声明会直接初始化函数对象，并把闭包引用挂上，如果函数体内还引用了另一个函数，得先把内部函数初始化完成,这个嵌套层级会加深执行栈的处理负担。
三个阶段的耗时中，解析和编译占据大头，执行阶段虽然耗时短，却因为闭包引用的存在,会拖住后续的gc内存处理。
node服务启动慢怎么排查先看函数级闭包链
服务端同样逃不开这个问题。node服务启动慢怎么排查，首要怀疑对象就是入口文件串联起来的函数级闭包链，启动时
require一个模块，Node会同步执行整个模块的顶层代码，包括内部所有函数的定义，如果这个模块是聚合导出的中心模块，内部引用了十几个子工具函数,启动就得把每个工具函数初始化一遍。
排查路径：
- 用
node --cpu-prof启动服务并抓取启动阶段的CPU profile。 - 在profiler里查看
EvaluateScript和CompileFunction事件的总耗时。 - 逐个展开耗时Top10的函数,确认它们是否属于同一个深层闭包网络。
处理方案也很直接，把这个中心模块改为按需require，把函数内部的引用改为参数注入,断开闭包的直接捕获。
小程序场景里的函数注入陷阱
小程序的首屏启动存在同样的隐患。小程序启动速度优化方案里，最常见的操作是主包与分包拆分，可如果你在主包内某个公共文件里导出了大量函数，即使分包页面不用它们，主包体积也会被拖上去,启动时小程序框架会先执行主包所有脚本。
这里更推荐的做法是：主包里只保留App启动真正调用的函数，其余全部放进分包，分包页面通过require.async按需拉取，避免在公共文件顶层用对象字面量集中导出所有函数,改为每个函数独立成文件。
用最小代价干掉函数级依赖包袱
既然问题定位清楚了，接下来就是动手改，这里的核心思路是：削减函数声明总量，切断函数与函数之间的静态引用，让启动时引擎不必为“用不到”的代码分配执行空间。
给代码打上pure标记，让tree shaking深入函数内部
项目里对不产生副作用的函数，建议在调用位置所在模块顶部声明/#__PURE__/注释，webpack和Terser识别后会直接将这个调用视为纯表达式,在未使用其结果时整段删除。
// 优化前
const baseApi = createApi({
baseURL: 'https://api.example.com',
timeout: 15000,
});
// 优化后
const baseApi = /#__PURE__/ createApi({
baseURL: 'https://api.example.com',
timeout: 15000,
});
这只是简单的例子，真正复杂的是在导出时也标记：export const utils = /#__PURE__/ {...}，让打包器知道这个对象构建过程没有副作用,可以安全移除未被读取的属性。
用sideEffects字段做模块级兜底
在package.json里声明"sideEffects": [".css", ".scss"]，告诉打包器除了样式文件外，其余JS代码均无副作用，这个动作能将未被引用的模块级导入直接剪除，和函数级pure注释配合,双管齐下。
rollup适合处理纯函数库
如果你维护的代码是一个纯函数工具库，建议把构建工具换成rollup，行业共识认为，rollup对函数级依赖的静态分析和tree shaking能力比webpack更彻底，它能真正删除未使用的函数以及该函数私有引用的其他函数,而不是像webpack那样保守地保留整个模块。
团队协作层面固化规范
要在长期内维持启动性能，光靠一次优化不够,建议在代码审查里加上这些检查项：
- 禁止在新代码里通过
export from './utils'做全量重导出 - 要求工具函数必须单独成文件，禁止多个函数挤在一个模块里互相闭包引用
- 每次改动后跑一次bundle分析，diff函数依赖数量的变化
- 给ESLint配置
import/no-unused-modules规则，自动发现未被引用的导出
成本路线的选择：自己动手还是花钱
函数层依赖的优化并不总是需要招新人，也不一定非要推翻代码，视项目脏乱程度，你可以自己按上文步骤做一轮清理，也可以请外部团队做专项处理，如果想邀外部聊聊，市面上的前端性能优化报价跨度很大，有的按天收，有的按项目打包，具体数额和团队所在地有关，一线城市和二三线城市的接单价格差异很明显,建议多问几家再决定。
如果你目前正在负责一个老项目，手里有预算，但不算充裕,可以优先做三步：
- 只优化首屏加载链路上的函数级依赖,不动其他页面。
- 给最重的工具库配置
sideEffects并重新构建。 - 用profiler对比优化前后的FCP和LCP指标。
这三步花不了半天，成本基本为零,往往能让启动时间有明显回落。
别急着加服务器或升级带宽，启动快慢很多时候不是网络传输问题，而是本机引擎解析问题，即便把资源全放到CDN，函数层依赖的体积依然会在浏览器本地消耗时间,加服务器只是掩盖了真实瓶颈。
优化函数层依赖的本质，是让启动阶段少做点无用功，代码写得克制一些，引擎工作就能轻松一些,启动自然就快了。
Q&A：函数层依赖包体积和启动速度的常见疑问
函数级依赖和模块级依赖，哪个对启动影响更明显？
模块级依赖决定了加载文件的总量，函数级依赖决定了单个模块内被解析代码的量，多数情况下，模块级依赖优化到位后，函数级依赖会成为新的瓶颈，因为模块拆分得越细，每个模块内部遗留的未使用函数占比就越高,启动时解析总量反而可能上升。
压缩代码能不能顺带解决函数层依赖的体积问题？
不能，压缩只是去掉注释和缩短变量名，函数的声明数量和闭包引用关系不会变，引擎解析的AST节点数也没有减少,启动耗时几乎不受影响。
tree shaking已经开启了，为什么包体积还是很大？
你可能没有给第三方库配置正确的sideEffects，或者你正在使用barrel文件统一导出内部函数，barrel文件会把所有函数聚合到一层再导出，tree shaking无法跨过这层判断每个函数是否被真正消费，解决方案是删除barrel文件,直接按文件路径导入对应的函数模块。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/643025.html
