郑州小程序组件开发避坑实录

上周帮一个做本地生活服务的客户改代码，他们之前找的外包团队把整个首页写成了一个 800 多行的 wxml，改一个轮播图的间距要翻三屏才能找到位置。我在郑州做小程序开发这些年，这种代码见得太多了。组件化这件事说起来简单，真落到项目里，坑比想象的多。今天就把我踩过的、见过的组件开发问题整理一下，都是能直接用的经验。

先想清楚：什么该抽成组件

很多新手容易走两个极端：要么什么都往页面里堆，要么恨不得每个 div 都封一个组件。我的判断标准其实很朴素：

• 同一个结构在三个以上地方出现，抽；
• 有独立的状态逻辑，且这个逻辑跟页面主流程没强耦合，抽；
• 纯展示、只出现一次的东西，别抽，抽了反而增加跳转成本。

举个例子，郑州这边不少餐饮、零售类小程序都有「门店卡片」这个模块——列表页有、详情页有、搜索结果里还有。这种就特别适合抽成组件，把门店名、距离、营业状态、优惠标签都做成 properties，页面只负责传数据。

组件通信别只会 properties

微信小程序组件通信有几种方式，很多人只知道 properties 和 triggerEvent，其实还有 selectComponent 和 relations。我的习惯是：

父传子用 properties，但要做类型和默认值

见过太多组件不写 type 和 value，父组件少传一个字段就报错或者渲染出 undefined。规范写法：

Component({
  properties: {
    shopName: { type: String, value: '' },
    distance: { type: Number, value: 0 },
    tags: { type: Array, value: [] }
  }
})

这样父组件漏传也不会崩，调试时心里有底。

子传父用 triggerEvent，事件名要有前缀

事件名我一般加业务前缀，比如 shopcard:tap，避免和内置事件或者别的事件撞名。页面里 bind 的时候一眼能看出来源。

跨层级别硬传，用 relations 或者全局状态

之前有个郑州本地的连锁品牌客户，做的是一个会员卡组件嵌套在列表组件里，要通知最外层刷新。硬用 properties 一层层往下传，代码非常难看。后来改成 relations 声明父子关系，子组件直接调父组件方法，清爽很多。当然，如果状态复杂，直接上 mobx-miniprogram 也行，别死磕。

样式隔离这个坑，一定要提前定规矩

小程序组件默认是 styleIsolation: 'isolated'，页面样式影响不到组件内部。这本来是好事，但很多团队没约定，结果组件里写了一堆全局类名，页面里又覆盖不了，最后加 !important 硬怼。

我的建议是：

• 组件内部样式统一用组件名做前缀，比如 .shop-card__title；
• 需要外部微调的，用 externalClasses 暴露出去，别直接改内部类；
• 确实要共享样式的，用 addGlobalClass: true，但要在团队里说清楚哪些类名是公共的。

这套规矩定下来，后面接手的人少踩一半坑。知码客在给郑州客户做小程序定制开发时，项目启动第一件事就是把组件规范和样式约定写进文档，比事后返工省事得多。

性能：组件不是越多越好

组件多了，setData 的链路也变长。有几个点值得注意：

• 列表项组件别在组件内部再监听滚动或者做复杂计算，数据在页面层处理好再传下去；
• 频繁更新的字段单独抽出来，别整个对象 setData；
• 纯展示组件可以用 pureDataPattern 减少不必要的渲染。

之前有个做社区团购的小程序，商品列表每个 item 都是组件，结果滚动卡得不行。后来把 item 里的价格计算、库存判断全挪到页面层，组件只负责渲染，帧率立刻回来了。

写在最后

组件开发这件事，技术本身不难，难的是团队约定和长期维护。郑州做小程序的公司不少，但真正把组件规范落到项目里的不多。如果你正在郑州找小程序开发团队，或者自己动手做，建议先把组件边界和样式规范想清楚再开工，后面会感谢现在的自己。我是知码客，专注小程序和 APP 开发，用代码改变生活，有问题欢迎交流。