唐山小程序组件开发避坑手记

做小程序这些年，我越来越觉得组件开发是分水岭。页面谁都能写，但组件拆得好不好，直接决定这个项目三个月后还能不能改得动。我是知码客，在唐山做小程序和 APP 开发，今天就把本地项目里踩过的组件坑摊开说说。

先说结论：组件不是越细越好

刚入行那会儿，我特别迷恋拆组件——一个商品卡片能拆成图片、标题、价格、按钮四个子组件，觉得这样复用性拉满。结果在唐山一个连锁烘焙店的小程序里翻了车：客户临时要把价格改成「会员价+原价」双行展示，我改了五个文件，改完发现另外三个页面也被牵连。那次之后我定了规矩：

• 组件边界按「业务语义」划，不按「视觉块」划；
• 一个组件只暴露一件事的接口，比如商品卡片只对外给 product 对象和 onTap 事件；
• 纯展示的碎片用模板或样式类解决，别硬抽组件。

properties 设计：别让父页面猜

组件最难的不是写，是让别人敢用。我见过太多组件，父页面传参全靠翻源码。我的做法是给每个属性写清楚默认值，并且用 observer 兜住异常输入：

Component({
  properties: {
    product: {
      type: Object,
      value: null,
      observer(val) {
        if (!val) return
        this.setData({
          priceText: val.memberPrice ? `¥${val.memberPrice}` : `¥${val.price}`
        })
      }
    }
  },
  methods: {
    handleTap() {
      this.triggerEvent('select', { id: this.data.product.id })
    }
  }
})

别小看这个 observer，它把「父页面传了脏数据」的风险挡在组件内部，比在每个页面里写 if 判断省事得多。

样式隔离：唐山项目里最容易被忽略的一环

微信小程序的组件默认样式隔离，但很多人直接开 styleIsolation: 'shared' 图省事，结果全局样式互相污染。我接手的唐山一个本地生活平台就是这样，改一个按钮颜色，首页和订单页全变。建议：

• 默认用 isolated，组件内部样式自己管；
• 需要外部定制时，用 externalClasses 开放有限接口，别整个放开；
• 字体、颜色这类设计变量放在 app.wxss 的 page 选择器里，组件里通过 CSS 变量读取。

本地客户案例：一个社区团购小程序的重构

去年帮唐山一个社区团购团队重构小程序，他们原来的代码是把「商品列表」写死在三个页面里，改一次活动价要同步三处。我们把商品卡片、规格弹窗、购物车角标抽成三个组件，页面只负责数据请求和跳转。重构后活动配置从半天缩到二十分钟，客户自己运营都能改。这就是组件化的真实价值——不是代码好看，是让不懂技术的人也能改得动。

几个小细节，踩过才知道

• 组件里的 this.data 更新是异步的，setData 之后别立刻读，用回调或 nextTick；
• 自定义组件嵌套超过三层，事件冒泡会变复杂，能扁平就扁平；
• 组件库别自己从零造，基础交互用官方扩展库，业务组件自己写，平衡成本和可控性；
• 上线前用真机测组件，开发者工具和真机的 rpx 表现偶尔有差异。

写在最后

组件开发没有标准答案，但有一个判断标准：三个月后你或者别人接手这个项目，能不能在不看文档的情况下用对组件。在唐山做小程序，客户多是本地实体商家和创业团队，预算有限、需求变化快，组件拆得稳，后期改需求才不至于推倒重来。我是知码客，专注小程序和 APP 开发，用代码改变生活，下次聊聊云开发在小项目里的取舍。