前端拆包怎么切，我按使用频率分三层
那个简笔画画板两天写完，页面上线后我打开开发者工具，请求列表拉了一屏。前端拆包策略怎么定，我的答案就一句：按使用频率切三层。不是按目录切，也不是按体积切。
按目录切的问题是，目录结构反映的是代码的组织方式，不是用户的访问方式。切完你会发现首屏该带的还是带着。
一、第一层：所有页面都用的，也是前端拆包策略的地基
这一层是骨架，比如框架运行时、全局样式、基础工具函数。
它的特点是人人都要，所以不该被懒加载。这一层的目标不是变小，是别重复。同一个库被打进多个分块，用户就要多下一份。
动作：把这一层单独固定成一个分块名，构建后确认它只出现一次。
二、第二层：首屏和主要路径用的
这一层跟着首屏一起加载，包含首屏组件和它的直接依赖。
判断标准是「不做交互也要用到」。首屏文字、图标、主按钮的样式算；点开弹窗才用到的那部分不算。
动作：把首屏必须的资源列出来，检查有没有混进只在二级页面用的东西。
三、第三层：少数路径才用的
这一层是懒加载区，比如设置页、帮助页、不常打开的编辑器。
它的体积可以很大，因为不进首屏。吞掉体积的不是它，是本来该在它里面的东西跑到了首屏。
动作：给这一层单独设一个名字，别让构建工具把它们合并回主块。
四、给稳定的第三方依赖单独留一层
框架和体量大的三方库版本变动慢，值得单独成块，这样业务代码改了用户的缓存还能用。
代价是这块一旦升级，缓存全废。所以只留真正稳定的那几个，别把所有依赖都塞进来。
还有一条不能忘：先量再切，切完再看。拆包很容易越拆越碎，分块太多，请求数量上去，弱网下反而更慢。
动作：切之前记一次首屏要下多少，切完再记一次。没有前后对比的拆包，等于闭着眼睛改。如果只是分块变多而首屏总量没降，就是白拆。
五、别让一个改动静默地影响所有块
公共层最容易出这个问题：往公共层里加一点东西，所有页面的缓存同时失效。
动作：公共层只放真的全局的东西，业务相关的都往下沉。判断方法是想一想「这个改一次，用户要重下多少」——如果答案是全部，它就不该在公共层。
优先级：先做哪个
顺序很清楚。先把公共层固定住，这一步收益最大也最不容易出错；再做首屏瘦身，把不该在首屏的东西挪走；最后才做细粒度切分，这一步收益最小、维护成本最高。
三层切完就停手。继续往下切，收益会递减到要靠运气才能测出来。
前端拆包策略怎么定，最后落到一句话：按用户什么时候需要来切，不按代码放在哪来切。
常见问题
Q：前端拆包策略怎么定，按目录切行不行？
A：不建议。目录反映代码怎么组织，用户怎么访问才是拆包的依据，按使用频率分三层更接近真实访问路径。
Q：拆得越细越好吗？
A：不是。分块过多会增加请求数量，弱网下反而变慢，切到三层并确认首屏总量下降就该停。
Q：怎么判断一个模块该不该懒加载？
A：看它在首屏有没有出现。不做任何交互就看不到的，基本都可以懒加载，按这个标准过一遍通常能挪走不少东西。
相关阅读
本文作者西米，37 岁程序员，一个人加五个 AI 员工在跑一家公司。踩过的坑和真实账本都写在公众号「西米分享」。
完整代码、踩坑清单与最新进展，都在公众号。
📱 关注公众号「西米分享」