还在为微信小程序的behavior烦恼？教你一招轻松复用代码！

最近跟几个做前端的朋友聊天，发现很多人对微信小程序的 behavior 还停留在“知道有这么个东西”的阶段，真正用起来却总觉得别扭。说实话，这个特性确实有点绕，但它其实是一个特别实用的代码复用工具。你要是写过 Vue，可能会想到 mixin，behavior 跟它确实有点类似，但又不完全一样。简单来说，behavior 就是一组可以复用的代码片段，包含属性、数据、生命周期函数和方法。你可以在多个页面或组件里引用同一个 behavior，这样就能避免重复写相同的逻辑。比如一个需要用户登录才能操作的页面，你完全可以把登录校验的逻辑抽成一个 behavior，然后每个页面引用一下就行，省事儿不少。

但问题来了，很多人觉得 behavior 不好用，主要是因为它引入了一些“隐式”的依赖关系。你写了一个 behavior，引用它的页面或组件里，可能突然多了一些你不知道从哪来的数据或方法，看着就让人头大。比如你在 behavior 里定义了一个叫 userInfo 的数据字段，然后在页面里也定义了同名的 userInfo， 那到底以谁为准？微信小程序的处理规则是：如果页面和 behavior 有同名数据字段，页面自己的数据会覆盖 behavior 的。但如果是同名方法，情况就复杂了——如果 behavior 里定义了 onLoad ，页面自己也定义了 onLoad， 它们会按顺序执行，而不是简单的覆盖。这种设计本身是为了灵活性，但你要是没搞清楚这些规则，调试起来真的要抓狂。

我见过一个项目，团队里有个新人写了一个 behavior，里面定义了 onShow 生命周期，结果引用了这个 behavior 的页面每次切换回来都会触发两次 onShow。排查了半天，发现是 behavior 和页面里都写了 onShow，且都没有做合并处理。微信小程序的处理逻辑是把 behavior 和页面的生命周期函数合并成一个数组，按顺序依次执行。如果你在 behavior 里写了 console.log，页面里也写了，那控制台就会输出两次。这还不算最坑的，要是 behavior 里定义了一个方法，页面里也定义了同名方法，页面里的会覆盖 behavior 里的。但如果你在 behavior 里调用了同名方法，实际调用的会是页面里的版本，这就容易让人产生困惑。

其实 behavior 的设计初衷是好的，它想让你把一些通用的逻辑抽出来，比如用户登录态检查、数据埋点、页面权限控制等。我见过一个做得比较规范的项目，他们把所有的数据请求错误处理逻辑都封装成了一个 behavior， 每个页面只需要引用一下，然后在自己的 onLoad 里调用 behavior 提供的请求方法，就能自动处理错误提示和重试。这样一来，每个页面只需要关注自己的业务逻辑，错误处理这种脏活累活全交给 behavior 去干。比在每个页面里复制粘贴一堆 try‑catch 要优雅得多，也更容易维护。

但 behavior 也有局限性。最让人头疼的是调试困难，因为你很难一眼看出某个数据或方法到底是从哪个 behavior 来的。要是项目里引用了多个 behavior，且这些 behavior 之间还有依赖关系，那简直就是一个迷宫。比如 behaviorA 依赖 behaviorB， behaviorB 又依赖 behaviorC，你在页面里引用了 behaviorA，结果发现页面里莫名其妙多了一堆来自 behaviorC 的数据。这时候只能层层追溯代码，特别烦人。而且微信小程序的开发者工具对 behavior 的支持也不是很完善，调试起来没有 Vue 的 mixin 那么直观。

我的经验是， behavior 适合封装那些“横切关注点”，即跟业务逻辑关系不大但很多页面都需要的东西。比如用户登录态检查、页面访问日志、权限控制、统一的数据加载错误处理。这些用 behavior 封装，确实能减少重复代码。但如果想把某个业务逻辑抽出来复用，比如购物车的逻辑，就要慎重。业务逻辑通常与具体页面强相关，抽成 behavior 反而会增加复杂度，不如直接写个独立的组件或工具函数来得清晰。

还有一个容易被忽视的点是 behavior 的生命周期执行顺序。微信小程序的页面和组件生命周期本身就很复杂，再加上 behavior，执行顺序就更难把握了。比如一个页面引用了两个 behavior，它们都定义了 onLoad，执行顺序是按照引用顺序来的。但如果 behavior 本身又引用了其他 behavior， 就会先执行子 behavior 的 onLoad， 再执行父 behavior 的。这种嵌套关系一多，你很难在脑子里模拟完整的执行路径。我之前调试过一个 bug，就是因为 behavior 的 onLoad 里做了一些初始化操作，而页面的 onLoad 里依赖这些结果，结果因为执行顺序问题，页面拿到的数据是空的。

说到底， behavior 是一个工具，工具好不好用，关键在于使用方式。如果能遵守一些基本原则——每个 behavior 只做一件事、不要过度嵌套、命名要清晰、文档要写明白—— behavior 就能提升开发效率。但如果把它当成万能药，什么逻辑都往里塞，迟早会把自己绕进去。我见过最夸张的项目，一个 behavior 里包含十几个方法和七八个数据字段，还引用了另外三个 behavior， 看代码的人直接崩溃。

所以我的建议是， behavior 适合解决小范围、明确的代码复用问题。比如项目里有十个页面都需要在进入时检查用户是否登录，抽一个 loginCheck 的 behavior 就很合适。但如果想用 behavior 实现一个复杂的业务逻辑复用，比如完整的表单验证逻辑，倒不如拆成多个独立的工具函数或自定义组件，这样更清晰，也更容易测试。毕竟代码是写给人看的，可读性比所谓的“复用”更重要。