微信小程序computed

打开微信开发者工具，新建一个页面，往data里塞几个字段，然后在wxml里写一堆花括号表达式——这是大多数小程序开发者的日常。但写着写着你会发现，有些数据它不是孤立的，它得靠别人算出来。比如购物车里的总价，得拿单价乘数量，还得加上运费减去优惠。你当然可以在每次数据变化时手动更新这个值，但保不齐哪个角落漏了一处，页面显示就错了。这时候你就想，要是能有个东西，自动帮我把这个计算逻辑管起来，数据一变它就跟着变，那该多好。

这个需求，前端圈子管它叫computed，也就是计算属性。Vue里有，React里能用useMemo模拟，小程序呢？官方没给，但社区里有方案。说白了，就是监听你依赖的那些数据，一旦它们变了，就重新跑一遍你定义的函数，把结果塞回data里，页面自然就刷新了。听起来不复杂，但真要在小程序里实现，坑比想象中多。

先说说最简单的做法。小程序页面里有个setData方法，你可以在每次修改源数据的时候，手动调用一次计算逻辑，把结果setData进去。比如你有个商品列表，每个商品有价格和数量，你想算总价，那就写个方法，遍历列表，累加，然后setData。每次增删商品、改数量，都得记得调这个方法。麻烦在哪儿呢？你得保证所有修改数据的地方都调用了。要是哪天加了个新功能，直接push了一条数据，忘了调，页面上的总价就错了。这种bug，排查起来特别费劲，因为不是必现，得看操作路径。

稍微讲究点的做法，是用Observer。小程序组件里有observers字段，能监听某个数据字段的变化，然后执行回调。你可以把总价放在一个独立的字段里，然后observers监听商品列表和运费这些字段，一旦它们变了，就在回调里重新计算总价。这比手动调用强多了，至少不用在每个操作点都写一遍。但注意，observers监听的是整个字段，如果你的商品列表是个数组，哪怕只改了一个元素的某个属性，整个数组的引用可能没变，这时候observers可能不触发。你得用setData去改那个元素，让数组引用变化，才能触发回调。这个限制，很多人一开始不知道，踩坑踩得莫名其妙。

再高级一点，有人写了库，比如miniprogram-computed，或者用Behavior封装一套响应式系统。这些库的思路，是在组件实例上劫持setData，或者用Proxy包一层data，当数据读取时收集依赖，当数据修改时触发重新计算。听起来挺玄乎，但实际用起来，体验确实接近Vue的computed了。你在computed字段里定义好计算逻辑，然后在wxml里直接绑定它，剩下的库帮你搞定。不过，这类库对项目侵入性比较强，你得按它的规范来写组件，老项目想引入，得花时间改造成本。

有个细节值得琢磨：computed的缓存问题。你在Vue里用computed，它是有缓存的，依赖不变就不会重新计算。小程序里自己实现，如果每次访问都跑一遍函数，性能上可能吃不消，尤其是计算逻辑复杂、页面频繁渲染的时候。但要是做缓存，又得考虑依赖跟踪的粒度。你监听整个data对象，那任何数据变化都会导致所有computed重新计算，缓存就形同虚设。你监听具体字段，那又得手动声明依赖，麻烦。所以很多小程序里的computed方案，干脆不做缓存，每次setData后统一算一遍，数据量不大时，影响也不明显。

还有个容易忽略的点：computed和异步操作的组合。你有个计算属性，依赖一个从服务器拉取的数据。数据没回来时，计算结果是undefined，页面得显示占位符。数据回来后，computed自动更新，页面刷新。这在逻辑上没问题，但如果你在computed里写了异步请求，比如根据某个ID去查详情，那就不合适了。computed应该是纯函数，输入确定，输出就确定，不能有副作用。异步请求应该放在watch或者事件处理里，把结果存到data，再让computed去依赖这个结果。这个边界，很多人写的时候容易混。

再聊聊性能。小程序的setData是个很重的操作，它会把数据从逻辑层传到渲染层，数据量一大，页面就卡。computed用多了，每次依赖变化都触发setData，如果页面里还有列表渲染，那就雪上加霜。所以用computed的时候，得想想计算出来的值，是不是非得放在data里。如果只是模板里用一下，可以考虑用wxs。wxs是小程序自己的脚本语言，能在模板里直接写计算逻辑，而且它运行在视图层，不经过setData，性能好。但wxs的语法受限，不支持ES6，写复杂逻辑很别扭。所以，轻量计算用wxs，重量计算用computed，这个取舍得看场景。

说到底，微信小程序没有官方的computed，不是因为它不重要，而是因为小程序的架构和Vue这类框架不一样。小程序逻辑层和视图层是分离的，数据传递靠setData，天然就不适合做细粒度的响应式。社区里的方案，都是在setData的基础上打补丁，能解决大部分问题，但总有些边角料处理不干净。你要是项目不大，手动算算也无妨；要是项目复杂，那就得认真选型，别等代码写了一半再回头改。

我见过有些团队，为了用computed，硬是把小程序页面改成自定义组件，用组件的observers去模拟。结果组件化改造动了全局样式，又引入一堆新问题。还有团队，用第三方库，结果库的作者不维护了，小程序基础库一升级，库就崩，整个项目跟着遭殃。这些教训说明，computed这东西，好用是好用，但代价你得掂量清楚。

回到开头说的那个购物车总价。如果你只是算个总价，手动setData也费不了多少事。但如果你有几十个这样的计算逻辑，分布在各个页面里，手动维护的代价就上来了。这时候，一个统一的computed方案，能省不少事。但方案选型，得结合你项目的实际情况，别盲目追新，也别因噎废食。小程序生态里没有银弹，computed只是其中一个工具，用好了是助力，用不好是负担。