微信小程序采用组件化开发模式后，组件的复用性和可维护性明显提升，但组件生命周期与页面通信的细节却常常被开发者忽视。很多莫名其妙的bug，比如组件内数据没有初始化、事件回调没有触发、父页面拿不到组件实例，根源都在于对生命周期执行顺序和通信机制理解不到位。本文从组件生命周期入手，结合页面与组件之间的多种通信方式，总结一套在实际项目中可落地的最佳实践。
一、组件生命周期的完整流程与关键钩子
小程序自定义组件的生命周期指的是组件从创建、挂载、更新到销毁的整个过程。在Component构造器中通过lifetimes字段声明，常用的钩子包括created、attached、ready、moved、detached五个。理解每个钩子的触发时机，是正确编写初始化逻辑的前提。
created钩子在组件实例刚刚被创建时触发，此时组件还不能调用this.setData，也不能访问this.data以外的属性，因此这个阶段只适合做一些简单的字段赋值。attached钩子在组件进入页面节点树时触发，绝大多数数据请求、定时器初始化都应该放在这里，因为此时组件已经可以调用setData，也能拿到properties传入的初始值。ready钩子在组件布局完成时触发，如果要获取节点尺寸信息，比如通过SelectorQuery查询元素高度，必须等到这个阶段才能拿到准确结果。
Component({
lifetimes: {
created() {
// 此时不能调用 setData，只能做简单赋值
this.initFlag = true;
},
attached() {
// 组件已进入节点树，可以发起数据请求
this.fetchData();
},
ready() {
// 布局完成，可以获取节点尺寸
wx.createSelectorQuery().in(this)
.select('.container')
.boundingClientRect(rect => {
console.log('容器高度：', rect.height);
}).exec();
},
detached() {
// 组件销毁，清理定时器与事件监听
if (this.timer) {
clearInterval(this.timer);
}
}
}
})
除了组件自身的生命周期，还有一类特殊的页面生命周期钩子，通过pageLifetimes字段声明，包括show、hide、resize三个。它们监听的是组件所在页面的状态变化。一个典型场景是TabBar页面中的组件，当用户切换到其他Tab再切回来时，组件需要在pageLifetimes.show里刷新数据，因为此时组件的attached不会重复触发。另外需要注意，旧版本的lifecycle字段写法已不推荐，统一使用lifetimes即可，避免新旧两种写法混用导致钩子不执行。
二、页面与组件通信的四种常用方式
小程序中页面与组件之间的通信没有全局状态管理时，主要依赖四种方式：properties属性传值、triggerEvent自定义事件、selectComponent实例调用、observers数据监听。每种方式各有适用边界，选错方式往往就是通信失效的开始。
第一种是父传子的properties方式，这是最规范的通信手段。父页面在WXML中以属性形式传值，子组件在properties中声明接收类型与默认值。需要特别注意的是，properties是单向数据流，子组件内部不应该直接修改properties的值，否则在父组件重新传入新值时，子组件内部的修改会被覆盖，产生难以排查的数据不一致问题。
// 父页面 WXML: <user-card user-info="{{userInfo}}" bind:refresh="onRefresh"/>
Component({
properties: {
userInfo: {
type: Object,
value: {},
observer(newVal, oldVal) {
// 属性变化时触发，旧写法，推荐用 observers 代替
console.log('userInfo 变化：', newVal);
}
}
},
methods: {
onTap() {
// 子向父通信：触发自定义事件
this.triggerEvent('refresh', { type: 'all' });
}
}
})
第二种是子传父的triggerEvent机制。组件内部通过triggerEvent抛出事件，父页面在WXML中用bind:事件名绑定回调函数。这里有个高频踩坑点：如果组件在构造器中设置了options.styleIsolation或者组件模板嵌套，事件冒泡行为可能与预期不同，triggerEvent默认不冒泡，除非第二个参数options中设置bubbles为true。第三种是selectComponent实例调用，父页面通过this.selectComponent('#id')拿到组件实例后可以直接调用其方法。这种方式虽然方便，但会打破单向数据流，让数据流向难以追踪，只建议在弹窗控制这类简单场景使用，例如调用自定义弹窗组件的open方法。第四种是observers字段，它可以同时监听data和properties的变化，支持监听对象内部字段，写法为'userInfo.name'这种路径形式，比旧版observer回调更灵活，是数据联动逻辑的首选。
三、大型项目中的通信架构与避坑建议
当页面嵌套层级较深，比如页面包含商品卡片组件，卡片里又包含价格组件，如果每一层都通过properties透传、triggerEvent逐层上报，代码会变得极其臃肿，这也就是所谓的逐层传递地狱。此时应该引入更合理的方案：轻量场景使用全局事件总线，复杂状态使用小程序自带的全局数据或第三方状态管理库。
全局事件总线的实现思路很简单，利用一个空的模块作为消息中心，页面和组件分别注册与触发事件，从而实现跨层级通信。不过事件总线也带来维护难题，事件名散落各处，时间久了没人说得清哪个事件在哪里被监听，因此事件名必须集中常量管理，并且组件销毁时务必在detached中移除监听，否则会造成内存泄漏与重复回调。
// utils/bus.js
const listeners = {};
const bus = {
on(event, fn) {
(listeners[event] = listeners[event] || []).push(fn);
},
off(event, fn) {
if (!listeners[event]) return;
listeners[event] = listeners[event].filter(f => f !== fn);
},
emit(event, data) {
(listeners[event] || []).forEach(fn => fn(data));
}
};
export default bus;
// 组件中注册并在销毁时移除
Component({
lifetimes: {
attached() {
bus.on('cart-updated', this.onCartUpdate = (data) => {
this.setData({ count: data.count });
});
},
detached() {
bus.off('cart-updated', this.onCartUpdate);
}
}
})
最后总结几条实践原则：其一，严格遵循单向数据流，父到子用properties，子到父用triggerEvent，selectComponent只做行为调用不做数据修改；其二，初始化请求放attached，节点测量放ready，清理工作放detached，Tab页组件用pageLifetimes处理显隐刷新；其三，超过两层嵌套的通信就应考虑事件总线或全局状态，避免逐层透传；其四，跨组件共享的响应式数据如果结构复杂，可以直接使用MobX风格的小程序绑定库，通过store绑定让多个组件自动同步更新。把这些规则固化到团队规范中，组件代码的可维护性会有质的提升。