微信小程序这玩意儿，仿佛压根儿没想过要像传统软件那样讲个宏大的架构，要么堆满那些教科书里常见的“设计模式”。对于大量老手来说，拼个 App Store 的图标，做个录入功能，还能跑通流程，就已经算搞定了。但它不一样。微信是个场域，你得懂这个场域的脾气。 那会儿做小程序，总认定是换个界面，换个技术栈，重点就在那套 API 上。结局呢？用了一堆现成的框架，代码读起来像块黑色的砖，根本没人敢拆。
实际上目前的中小团队，根本没人有精力去维护那么复杂的大系统。更真的做法，是把那个 App Store 做，把包结构设计好，然后像搭积木一样，一个个功能模块接上去。 我在开发一个天气工具的时候，就踩过这个坑。老板让用某个框架，结局那框架里的封装忒深，我想加个“自定义单位”要么“自动换算”的功能，就得写一堆逻辑层。
那一刻特别难受，感觉自己在帮系统打工。
后来我实际上想做的，就是一个轻量级的工具，用户想要“华氏度”就一键切换，想要“摄氏度”就一键切换。
为啥非要写后端逻辑呢？出于你要寻思的是，用户打开小程序，是不是只想看一眼数据，而不是去研究你的代码。
故此，我不贴那层厚厚的封装皮，直接把逻辑写在 Diанны 里，要么干脆用 `wx.setEnv` 这种轻量级的配置方式，灵活得像水一样。 数据量不是难题。大量教程会说，后期数据要上到云端，做高并发，那纯属扯淡。小程序的体量，实际上就在这个层级。
你想做一个赞成一百万级日活的工具，那没难题；想做到百万级月活，那是另一回事；百万级日活，那是常态。我们不需求去折腾 Redis 集群要么消息队列，那些本身就是为了解决那些根本不需求的话做的。
要是你的功能确实充足轻，好办粗暴地用本地存要么好办的 WebSocket 推送，效率反而更高。 再说说交互。
那会儿总认定交互设计是美工的事件，目前发现，大量逻辑就在按钮组件里。
比如做一个“一键购买”的按钮，要是没点过，系统默认是“购买”，点了就是“取消”。
这就利用了小程序默认的上下文。
不需求写复杂的弹窗流程，不需求判断用户 ID，也不需求复杂的表单校验。用户点击，系统直接响应状态变化。
这种“默认值”机制，在小程序里特别好用，能让你省下不少事。 我也见过有人为了追求美观，在屏幕里堆满各种图片，结局加载慢，用户耐心不耐。
实际上，小程序的优势就是资源限制。加载一张图，资源包里就占个几十 KB。
要是你那个图片用几 G，那根本就没法买了。
故此，像我们用微信的那个天气组件，要么抖音那种精美的详情页，核心就是压缩，就是精简。 还有一个点，就是“它要能随时被删掉”。大量开发者会认定，做小程序就要终身维护，要写文档，要提需求，要出版本。
实际上不然。小程序的生命周期挺短，可能就是个用户APP 下载量。你的维护成本，就应当是“随时能关掉，明天再装”。代码结构要像搭积木一样，哪位删哪位拆，哪位改哪位改。
不需求那种“全局状态管理”，你要做的只是是状态变更，一个变量改一下就行。 最终，我想说，做小程序，不是为了展示你的技术深度，而是为了证明你的产品能在这个生态里活下来。你不需求写复杂的后台，你只需求写好的前端逻辑，让用户体验顺畅。
那个“一键购买”的按钮，那个“单位切换”的按钮，那些看似好办的功能，背后处理的是多少逻辑，但对外看，它就只是两个按钮。
这种“好办”与“复杂”的反差，就是小程序的精髓所在。
要是你能看透这一点，你的代码量就会比那些写框架的少得多，效率也会高出一大截。