1、图片上CDN
这个没什么好说的，如果你的项目里还存有除了tabbar图标以外的任何图片，请全部搬上服务器用链接的方式引用，一张图片≈几百行代码。只需要注意图片压缩，保证加载效率就行。
2、分包加载
详见小程序文档使用分包 | 微信开放文档
简单说就是除了主tab内的最多4个页面，其他页面全部分出去引用，不占主包容量。这个方式也是比较简单直接地去分流主包的内容，其实比较妥当方式是在起项目的时候就已经规划好分包了，但现实需要使用分包的时候往往是接手了一个大包圆，所以拆分包就是一个必要流程了，注意事项：
1）组件引用：多个分包引用到的组件，需保留在主包内（使用分包异步化可以不用，详见下文）
2）路径变更：分包页面路径一定会变，代码和服务端下发（如果有）引用新的路径
3）设置中转页：拆出去的分包，如果业务已经投放出去了，如贴上了二维码、页面设置了分享等，因为投放的路径已无法变更，所以需要在原路径留一个中转页，以防老用户走丢，中转页在onLoad方法里直接加一个redirectTo跳转过去就行了。
3、自定义组件/模板
详见自定义组件 | 微信开放文档 及 模板 | 微信开放文档
个人原则是一个功能不写两遍，所以我这儿基本看不到重复粘第二遍的代码。但回到现实，可能在老代码中脸熟的内容比比皆是。
这也是重要的一个优化途径，需要注意的是组件存放位置，如果是跨分包使用的组件，需要放在主包里才能全局引用，这可能也会变相增加一些主包空间。避免这种情况，可以使用分包异步化。
4、分包异步化
详见分包异步化 | 微信开放文档
如果是高度组件化开发，后期可能会出现主包里组件占有大量的空间、大部分组件并不在主包页面中使用的情况，这时候可能需要参考的就是进行分包异步化处理。
分包异步化可以支持跨分包引用组件，加上这个基本就可以保证主包中除了主页面相关的内容，不再有其他干扰项。当然这个功能是有副作用的，就是需要放弃一部分低版本用户，将基础库版本提上来，版本用户量可以在开发者工具中查看，当前这个时间来看除非应用是面向老年用户，强行提升基础库应该不会有什么损失（总比发不了版强）：
5、样式优化
这个就比较细碎了，有两种方式，用在成熟的项目上来说，动静都挺大的，但如果经历了前几项优化依然需要空间，不妨考虑下：
1）预编译样式拆解
挺多项目使用的框架预置了预编译的样式方案如less、sass等，一不注意就开始直接当成常规项目开始层层嵌套地去写样式了，结果编译出来的文件可能会占更多的空间，如下：
如此样式文件累加的情况下，还是多占了不少空间的，如果没有其他空间可释放，或者为以后考虑的话，还是建议把样式拉平，就是在已具规模的大项目中需要注意减少影响，所以搞起来会比较痛苦，需要注意的就是样式隔离组件模板和样式 | 微信开放文档。
2）通用样式合并
类似于安装 - TailwindCSS中文文档 | TailwindCSS中文网，当然如果可能还是建议在小程序起项目的初期就已经安排上了这一套。目前好像也已经出现了与小程序匹配的tailwind扩展，可用性未知，没试过。宗旨就是建立全局的通用样式表，合并重复的CSS样式内容，这样在样式上基本也就做到优化至极致了。
6、干掉业务
不开玩笑，如果已经对当前项目的业务比较熟悉的话，没事可以问问产品这个功能好久没见人用了，还要不要不要我可就删了啊，打工猿的话多一些沟通有时候能省很多事。
以上，空间这东西，挤挤总会有的，如果你正在准备起一个“大程序”，或者手上正好有一个随时会爆掉的大程序，希望有所帮助。
