插件化开发，让小程序更轻快

做小程序这些年，我越来越觉得，代码写得越顺手，越容易忽略一个现实：需求是会长大的。一个最初只想做个商品展示的客户，三个月后要加会员体系，半年后要接预约系统。如果一开始没想好扩展方式，后面每加一个功能，都像在已经装修好的房子里砸墙。

小程序插件，就是提前留好的那面承重墙。知码客在北京做定制开发，团队不大，但接的项目不少，插件化是我们这几年踩坑之后坚持下来的做法。这篇文章不聊虚的，说说插件开发里真正值得注意的地方。

插件不是万能药，先想清楚边界

微信官方对插件有明确的定位：可以独立开发、独立发布的组件集合，能被其他小程序引用。听起来很美，但有几个现实约束得先接受。

• 插件不能单独运行，必须依附于宿主小程序；
• 插件有自己的代码包限制，不能无限膨胀；
• 插件调用宿主能力需要显式声明，权限边界比普通页面更严格；
• 插件更新后，宿主需要重新提审才能生效，这点很多人第一次做会踩坑。

所以我的判断标准很简单：这个功能会不会被多个项目复用？会不会频繁改动？如果答案是“只此一家、改一次就完”，那老老实实写在主包里，别为了插件而插件。

一个北京本地项目的插件拆分实践

去年我们给北京一家做社区养老服务的机构做小程序，需求里有健康档案、预约上门、活动报名、家属端消息推送几块。客户当时提了一句：“以后可能还要接街道的其他服务点。”这句话让我们决定把预约和消息两块拆成插件。

拆完之后的好处很直接：主包体积从接近 1.8MB 降到 1.1MB 左右，首屏加载明显快了一截；后来客户新接了两个街道站点，预约插件直接复用，只改了配置项，省了至少两周工作量。这就是插件化最朴素的价值——不是炫技，是省事。

插件目录结构示例

plugin/
  components/
    booking-form/
      index.js
      index.json
      index.wxml
      index.wxss
  pages/
    booking-list/
  utils/
    date.js
  plugin.json

plugin.json 里要声明 publicComponents 和 pages，宿主通过 requirePlugin 引入。这里有个细节：插件内的组件样式默认隔离，想透传主题色，最好用 CSS 变量或者属性传参，别指望全局样式能漏进去。

宿主与插件的通信，别写成一锅粥

插件拿不到宿主的页面栈，也不能随便调宿主的全局方法。我们通常约定两种通道：

• 属性下发：宿主把用户身份、门店 ID 这类配置通过 properties 传给插件组件；
• 事件回传：插件通过 triggerEvent 把结果抛给宿主，由宿主决定跳转还是弹窗。

听起来简单，但实际项目里最容易出问题的是异步时序。比如插件初始化时去请求接口，宿主这时候还没拿到登录态。我们的做法是插件内部维护一个 ready 状态，宿主通过属性把 token 传进来后再触发加载，避免两边互相等。

Component({
  properties: {
    token: { type: String, value: '' }
  },
  observers: {
    token(val) {
      if (val) this.initBooking();
    }
  },
  methods: {
    initBooking() {
      // 拿到 token 后再发请求
    }
  }
})

给准备做插件的同行几句实话

第一，插件文档要自己写。代码可以复用，但配置项、事件、版本变更记录不写清楚，下一个接手的同事会骂人。第二，插件版本号要规范，宿主引用的版本一旦固定，插件升级要评估兼容性，别今天加个必填属性，明天线上就白屏。第三，插件不是越多越好，三个以内比较健康，多了之后调试链路会变得很长。

在北京做小程序定制，客户来自各行各业，需求差异大，但“稳定、可维护、能扩展”这几个诉求是共通的。知码客一直信一句话：知码识途，匠心铸客。插件开发不是什么高深技术，它更像一种提前替客户想一步的习惯。把边界划清楚，把通信约定好，剩下的就是老老实实写代码。

如果你手上有个项目正在纠结要不要拆插件，不妨先画一张功能复用图，答案往往自己就浮出来了。