小程序组件开发：别急着封装

组件开发这件事，我踩过的坑比写过的组件还多。刚做小程序那会儿，看到什么都想封装：按钮封装一个、卡片封装一个、连个带图标的文本行都要抽出来。结果项目做到一半，组件目录比业务代码还厚，改一个样式要翻五个文件。后来才想明白，组件不是越多越好，是该封的时候封，不该封的时候忍住。

什么时候才值得抽组件

我的判断标准很简单，满足下面任意一条才动手：

• 同一段结构在三个以上页面出现，且以后大概率还会加
• 这块 UI 有独立的状态逻辑，比如倒计时、轮播、表单校验
• 需要被不同项目复用，或者团队里多人协作要统一交互

反过来，只用一两次的布局块、纯展示且样式强依赖父容器的结构，老老实实写在页面里。抽出来反而增加心智负担，props 传一堆，最后发现还不如直接写。

自定义组件的基本骨架

微信小程序的自定义组件，核心就四个文件。先说 json，必须声明 component: true，否则就是个普通页面。

{
  "component": true,
  "usingComponents": {}
}

js 里用 Component 构造器，properties 定义外部传入的数据，data 是内部状态，methods 放事件处理。这里有个细节很多人忽略：properties 也能写 observer，但别在里面做太重的事，容易触发连锁更新。

Component({
  properties: {
    title: { type: String, value: '' },
    count: { type: Number, value: 0 }
  },
  data: { innerLoading: false },
  methods: {
    onTap() {
      this.triggerEvent('change', { count: this.data.count + 1 })
    }
  }
})

通信别只会 triggerEvent

父子通信是最常被问的。父传子用 properties，子传父用 triggerEvent，这是标准做法。但实际项目里经常遇到孙组件要改爷爷组件的状态，一层层 triggerEvent 往上冒，代码能写成一坨。

我的做法是：跨层级超过两层，就别硬传了。要么用 getApp() 挂全局状态，要么用 Behavior 抽公共逻辑。小项目用全局 store 完全够用，别一上来就上复杂的状态管理库，小程序包体积本来就紧张。

有个坑提醒一下：triggerEvent 的事件名不要用驼峰，用短横线或者全小写。曾经因为写了 triggerEvent('onChange')，父组件监听死活不触发，排查了半小时。

样式隔离和外部类

组件默认样式隔离，父组件的 class 影响不到里面。想让外部控制部分样式，在 Component 里配置 options: { addGlobalClass: true }，或者用 externalClasses 声明可外部传入的类名。后者更可控，推荐。

Component({
  externalClasses: ['custom-class']
})

但 externalClasses 有个限制，只能传类名，不能传具体样式值。如果设计稿要求动态颜色，还是得走 properties 传值，然后在组件内部用行内 style 绑定。

性能上容易翻车的地方

组件多了以后，setData 的调用频率会明显上升。几个实打实的建议：

• 只 setData 变化的那部分字段，别整个对象重新赋值
• 列表渲染的组件，key 一定要用稳定唯一值，别用 index
• 频繁更新的组件（比如计时器）把 setData 合并，或者用 wx.nextTick 控制节奏
• 纯展示组件可以考虑用 pureDataPattern 减少不必要的数据通信

之前做过一个实时刷新的列表，每个 item 都是独立组件，结果每秒几十次 setData，安卓低端机直接卡成幻灯片。后来把刷新逻辑收敛到父页面统一 diff，只更新变化的行，才恢复正常。

最后一句实在话

组件开发的能力，不在于你能封装多少，而在于你知道什么时候不封装。先把页面写清楚，等重复真的出现了，再回头抽。这样抽出来的组件，接口往往更干净，因为你是被真实需求逼出来的，而不是拍脑袋设计出来的。