1024kb 只是一个目前编译后代码可上传最大限制，至于后期会不会更改，不得而知。个人只是想借 1024kb 来和大家一起交流一下，如何在限制下，挥舞大刀…
微信官方回答了，为什么有 1024kb 的限制。 省流、空间占用少！ 那么如何有效利用1024kb？
对于开发微信小程序的程序员来说，你必须有一种”一分钱掰成两半花”的思想准备。
个人认为：在 1024kb 的有限空间内，能否做出更多的事情，这将是一个挑战。而我们该如何应对这个挑战呢？ 下面说说的笔者的几点看法：
- 官方规范，我相信，你今天可以不看，明天也可以不看，后天应该就要看看了吧
- 交互设计稿，简单一点，再简单一点，flex实现的九宫格、网格…
- UI组件，微信官方作为首选（参照UI设计规范，有能力的赶紧设计出几套简约风格的吧，也许将为你带来不小的收获）
- 代码复用。公共类、通用模块什么的，赶紧做起来吧
-
大道理的落地实现，举几个例子：
1 . 官方文档中的组件篇，封装了一些常见的组件，微信官方封转时充分考虑了移动端的多样性，进行了适配，我相信一般开发者做不到这么好的封装吧，切忌为了一些酷炫的效果，去自己封装组件，除非你足够牛X，再者，一共就 1024 kb，在封装组件上浪费大量空间，并不理智。如果这些不足以满足需求，还有WEUI
2 . 媒体组件必须使用时，避免使用本地资源，将这些占空间的内容放到服务端将更好；媒体资料使用压缩传输，下载到本地缓存内，进行解压展示，配合过期策略，将能在省流和较佳的媒体展示中找到你一个平衡点；如果做不到这些，就将媒体资料压缩后在传到服务器上吧
3 . 小程序提供本地缓冲，在安全的以保证的情况下，发挥它的作用吧。媒体资料建议不要滥用，如果可以用简单几句话可以表达你的意思的话。毕竟小程序 是一个“小应用”
4 . 交互设计稿布局方面，微信官方在Css Flexbox布局基础上，简化后创造的flex布局，官方推荐使用，使用时仅需对容器和元素进行简单的wxss样式设置即可得到自己的布局方案
5 . 基于模块化编程，提高代码复用性。将通用业务逻辑封装成模块，实现重用，将可节省大量空间去做更重要的事情