邯郸小程序组件开发实战记

我是知码客，在邯郸做小程序和 APP 开发。这几年接的本地项目多了，发现一个规律：凡是后期改起来特别痛苦的小程序，基本都是把代码全堆在页面里，一个 index.js 写到七八百行。组件化这件事，说起来像老生常谈，但真到项目里能不能落地，差别特别大。今天不讲概念，就聊聊我在邯郸几个项目里踩过的坑和最后沉淀下来的写法。

为什么邯郸的客户更需要组件化

本地客户有个很典型的特点：需求是分阶段冒出来的。比如先做个展示加预约，跑一段时间觉得不错，再加会员积分、加分销、加多门店。如果一开始页面里是复制粘贴的代码，第二期改一个按钮样式，得在五六个文件里找。组件化不是为了炫技，是为了让第二期、第三期的报价和工期能压下来，客户也不用为重复劳动买单。

我经手过一个邯郸丛台区的餐饮项目，最初只有点餐和排队两个页面。半年后加了外卖、储值、企业团餐，因为商品卡片、数量步进器、地址选择这些都抽成了组件，新增页面基本是拼装，改动集中在一处。反过来也见过反面案例，一个县里的农资商城，页面里三份几乎一样的规格选择逻辑，改价格显示规则时漏改了一处，线上出了两天错。

自定义组件的最小可用结构

微信小程序的自定义组件不复杂，四个文件：js、json、wxml、wxss。关键在 json 里声明 component: true，然后在使用方页面的 json 里注册。下面是我常用的商品数量步进器，几乎每个电商类项目都会用到：

// components/stepper/stepper.js
Component({
  properties: {
    value: { type: Number, value: 1 },
    min: { type: Number, value: 1 },
    max: { type: Number, value: 99 }
  },
  methods: {
    onMinus() {
      const v = this.data.value - 1;
      if (v < this.data.min) return;
      this.setData({ value: v });
      this.triggerEvent('change', { value: v });
    },
    onPlus() {
      const v = this.data.value + 1;
      if (v > this.data.max) return;
      this.setData({ value: v });
      this.triggerEvent('change', { value: v });
    }
  }
});

使用方只需要监听 change 事件，组件内部不碰业务数据。这条边界一定要守住：组件只管展示和交互，数据从哪来、存到哪去，交给页面。

三个容易翻车的细节

• 样式隔离。组件默认样式隔离，页面里的 class 影响不到组件内部。好处是不会互相污染，坏处是想改组件内部样式时改不动。我的做法是把可变的外观通过 properties 传进去，比如主题色、圆角大小，而不是让外部去覆盖 class。
• setData 的频率。组件里如果有滚动、拖拽这类高频交互，别每次事件都 setData。用节流，或者只在关键节点更新。之前一个邯郸本地的活动报名页，日历组件每次滑动都全量 setData，低端安卓机上卡得明显，改成只更新变化的日期区间后顺畅很多。
• 事件命名。triggerEvent 的事件名用业务语义，比如 submit、select、change，别用 click 这种和原生事件混淆的名字，不然排查问题时容易看花眼。

组件怎么划分才不别扭

我的经验是按“会不会在别处复用”和“逻辑是否自成一体”两条来判断。纯 UI 的，比如空状态、加载骨架、弹窗、标签选择，直接抽公共组件库；带业务属性的，比如订单卡片、门店选择器，放在业务目录下，别硬塞进公共库。公共库越干净，后面接新项目越省事。

组件不是越多越好。一个只有两行 wxml 的东西硬抽成组件，props 传参比直接写还长，那就是给自己找麻烦。

另外提醒一句，用 npm 引入第三方组件库时，记得在开发者工具里勾选“构建 npm”，并且把 miniprogram_npm 的路径配置对。这个问题我在帮邯郸本地一个做家政预约的团队看代码时遇到过，组件死活渲染不出来，查了半天是构建目录没对上。

写在最后

组件开发说到底是一种习惯：写页面前先想这块东西以后会不会再用。在邯郸做小程序，客户预算普遍务实，把重复劳动省下来，工期和报价才有空间。我是知码客，专注小程序和 APP 开发，平时就在本地跑项目，有组件拆分或者老项目重构的问题，欢迎一起聊。