小程序文档里反复提“页面”和“组件”但真正写业务时才会发现这两者的边界绝不是“文件放哪个目录”这么简单。我见过不少项目代码迭代两三个版本之后组件目录下躺着七八个只在一个页面用过的“组件”页面文件里却堆着两百行重复的卡片逻辑最后需求一变更光改数据联调就耗掉半天。这篇就把页面和组件的区别完整地过一遍定位、文件结构、生命周期、数据通信、样式隔离以及到底怎么判断一段代码该放页面还是该拆组件。内容以微信小程序的机制为准其他小程序平台的思路大体一致细节略有差异。适合刚接触小程序、被概念绕晕的开发者也适合想把项目结构整理清楚、正在纠结要不要拆组件的同学直接抄经验。1. 先搞明白各自的定位页面是场景组件是积木1.1 为什么小程序设计者要把它们拆成两套机制从文件组成上看页面和组件都是“四个文件js、json、wxml、wxss”很多初学者因此觉得它们本质上就是一个东西只是叫法不同。但从小程序框架设计者的角度看它们是两种完全不同的“公民”。页面是用户能直接打开和看到的完整场景。它是路由系统里的一个节点可以被跳转、分享、扫码直达也可能直接成为小程序的首页。页面承载的是“一次完整的用户任务”比如查看商品列表、填写订单、查看个人中心。页面需要知道自己什么时候被打开、什么时候被切到后台、什么时候被销毁所以它有一套和用户交互节奏强绑定的生命周期。组件则不一样。组件是一个可复用的局部视图单元它不具备路由身份不能脱离宿主页面独自展示。换个更直白的说法组件没有“出场权”只有“被使用”的权利。它感知不到用户从哪个页面进来、页面何时隐藏它只知道自己在节点树里被挂载、更新、移除。这个定位差异可以类比成积木和城堡的关系。组件是积木块页面是用积木拼出来的完整建筑。你可以把同一块积木用在多个城堡里但积木本身不等于城堡。小程序框架把这两种单元分开设计本质上是想让“可复用性”和“场景独立性”各自有清晰的边界而不是把所有东西都揉成一锅粥。理解了这个前提后面所有具体的差异都不需要死记硬背几乎都能推导出来页面有窗口配置、有路由能力、有独立的导航栏组件没有。页面默认使用全局样式和页面样式组件默认样式隔离。页面之间通过 url 传参父页面和子组件之间通过属性传值。逻辑一旦串起来写代码时就不容易犯糊涂。1.2 从文件结构一眼看出差别最直观的差异体现在项目目录和配置文件上。一个典型的页面目录是这样的app.json pages/ ├── index/ │ ├── index.js │ ├── index.json │ ├── index.wxml │ └── index.wxss └── detail/ ├── detail.js ├── detail.json ├── detail.wxml └── detail.wxss而这个项目里的组件目录可能是这样components/ └── my-card/ ├── my-card.js ├── my-card.json ├── my-card.wxml └── my-card.wxss文件后缀完全一样但配置文件里的含义却完全不同。页面在 app.json 里需要注册而且注册顺序还会决定小程序的首页{ pages: [ pages/index/index, pages/detail/detail ] }组件的配置文件里则是这样{ component: true }这个component: true是整个组件身份的开关。它向框架声明“我是组件不是页面”一旦少了这行组件实例化就会报错或者完全无法被正确识别。页面的 json 还会承载窗口表现类配置比如{ navigationBarTitleText: 首页, enablePullDownRefresh: true, backgroundTextStyle: dark }这些窗口级的能力只有页面才有组件 json 里写这些是无效的。原因很简单——组件不拥有独立窗口它寄居在页面内部窗口的属性当然由页面统一管理。我见过有同事把下拉刷新开关写进组件的 json改了半天没反应最后才发现组件根本管不了这些东西。1.3 页面是注册单位组件是被引用单位页面一旦在 app.json 里注册就会被路由系统纳入管理可以被navigateTo、switchTab、redirectTo这些导航接口直接打开。组件没有这个待遇它必须被某个页面显式引用之后才会生效。组件的引用方式是局部声明。在使用组件的页面 json 里通过usingComponents指定路径{ usingComponents: { my-card: /components/my-card/my-card } }然后在页面的 wxml 里这样使用my-card title标题 /这段声明有一个非常容易踩的坑路径写法。如果开发时使用了相对路径在页面和组件处于不同分包或不同目录层级时很容易出现编译正常但运行时组件加载失败的情况。我自己的习惯是组件引用路径全部写成绝对路径从根目录写起也就是以/开头这样可以最大程度避免跨分包时的路径解析问题。另外usingComponents不需要在 app.json 里按页面逐个注册也可以在 app.json 的usingComponents字段里做全局声明这样所有页面都能直接使用指定的组件。全局声明固然省事但会让每个页面的编译体积都带上这个组件即使某个页面根本没用它。组件多、分包大的项目我不建议一股脑全局引入按页面按需引用通常更稳。这个差异还带出一个很实用的判断标准组件不会因为代码在项目里就自动生效它必须被页面 json 显式引用一次而页面只要注册进pages数组就直接可以被用户访问。如果你发现某个组件改了代码页面却没反应先检查引用路径和usingComponents有没有写对而不是一头扎进组件内部逻辑里找原因。2. 生命周期各走各的时机不同能做的事也完全不同2.1 页面生命周期和组件生命周期的对比生命周期是页面和组件之间最分道扬镳的地方。页面知道用户什么时候进入、什么时候切后台、什么时候销毁组件对此一无所知。把它们并排放在一起看差别非常明显。类型生命周期触发时机典型用途页面onLoad页面初次加载可拿到跳转参数解析 query、初始化数据页面onShow页面每次进入前台显示刷新数据、恢复挂起状态、埋点页面onReady首次渲染完成初始化 canvas、地图等渲染相关操作页面onHide页面从前台进入后台但不销毁暂停定时器、保存临时状态页面onUnload页面被销毁释放全局资源、清理订阅组件created组件实例创建但尚未挂载到节点树初始化组件私有数据组件attached组件被挂载到节点树读取属性值、发起网络请求组件ready组件首次渲染完成查询节点、操作渲染层内容组件moved组件在节点树中位置变更处理位置迁移相关逻辑组件detached组件从节点树移除清理定时器、取消事件订阅这里最容易混淆的点有两个。第一个是created和attached很多新手以为created已经万事俱备实际上created只代表实例被创建了属性里的值还没有被完整传进来。等到attached时组件才真正挂到节点树上此时读取properties里的值才是安全的。第二个是页面有onShow的对应概念——它每次从后台回到前台都会触发所以适合做“每次都要刷新”的逻辑组件没有对应生命周期如果你在组件里想感知页面从后台切回来通常得由页面主动通知组件或者用一些间接手段去模拟这个后面细说。2.2 触发顺序页面和组件的生命周期是嵌套的页面上挂了组件之后两个生命周期的触发顺序并不是“先页面整套走完再走组件”而是交错嵌套的。大体顺序如下页面 onLoad页面 onShow组件 created组件 attached组件 ready页面 onReady从顺序可以看出页面在 onLoad 阶段还没有等组件挂载完成所以如果在页面 onLoad 里直接通过this.selectComponent去拿组件实例很可能会拿到空。稳妥的做法是在onReady之后再取组件实例因为那时组件已经 ready 了。这个顺序在调试跨端逻辑时特别重要。比如你要在页面加载时给组件传一个索引值组件拿着这个索引去请求详情数据。如果你在组件created里就发请求属性值还没到位请求参数就可能是 undefined改成attached里再发基本就稳了。这类问题排查起来特别费时间因为表面上看不是“报错”而是“数据不对”很容易让人怀疑是接口或者参数命名的问题。组件的moved生命周期平时用得少但有一个典型场景组件位于一个会被移动的列表节点中比如被拖拽排序或者跨容器移动时moved会触发。如果组件内部持有和位置相关的状态就需要在moved里做相应的重置逻辑。不过大多数项目里不会碰到知道这个生命周期存在即可。页面生命周期和组件生命周期还有一个更直观的差异组件的detached相当于页面级的onUnload。但页面onUnload之后页面就彻底没了而组件detached可能是因为被移除了也可能只是页面整体卸载时连带触发。如果组件里启用了定时器建议都在detached里清掉避免定时器残留导致的内存泄漏。2.3 生命周期选择的“经验法则”我自己写组件时有一条很朴素的经验能放attached的逻辑绝不提前到created能做在ready里的节点操作绝不当成普通数据逻辑处理。原因很简单——attached表示已经和节点的树结构产生关系读属性、发请求都足够安全ready表示渲染层已经就绪此时做wx.createSelectorQuery()才能准确定位到组件内部的真实节点。页面也有类似的选择逻辑。onLoad只做一次性的初始化工作比如解析页面参数、创建某些和页面同生命周期的对象onShow放每次进入页面都需要执行的动作比如重新拉取未读消息、恢复页面状态onReady做依赖渲染完成的操作比如初始化 canvas、绑定地图组件。如果你把应该放在onShow的逻辑写进onLoad最典型的结果是用户从页面 A 跳到页面 B再返回页面 A 时数据不会刷新因为onLoad不会再次执行。这里还有一个被问过很多次的细节页面和组件是否都能使用observers答案是都能用。页面的observers可以监听 data 中的字段变化组件的observers同样可以。但有个容易出问题的写法在组件里用observers监听一个由父页面传入的properties字段然后在回调里 setData这本身没错但如果父页面频繁更新这个属性组件observers就会高频触发里面的逻辑必须足够轻量。我见过有人把请求放在observers里父页面每次切换数据源都触发一波请求服务和流量成本都白白上升。属性变化需要“通知组件做事”时observers是合理的但需要“根据属性拉新数据”时先想想是不是应该由页面决定什么时候触发而不是让组件被动迎合每次变化。3. 通信与作用域页面管全局组件管局部3.1 组件对外只有三个口子属性、事件、插槽页面和组件之间的通信边界比很多前端框架要严格。组件对外只暴露三种通道properties属性、自定义事件、slot插槽。理解这三样基本就理解了组件如何与外部世界交互。属性传值负责把页面的数据单向传入组件。组件内部这样声明接收// components/my-card/my-card.js Component({ properties: { title: { type: String, value: }, itemId: { type: Number, optionalTypes: [String] } } })页面使用组件时把数据通过属性传进去my-card title{{pageTitle}} itemId10086 /组件要向页面发送消息用triggerEvent触发自定义事件// 组件内部某个点击回调中 this.triggerEvent(cardtap, { id: this.data.itemId });页面监听这个事件my-card bind:cardtaponCardTap /slot插槽则允许页面把自己的视图内容塞进组件内部指定位置my-card title推荐位 view classcustom-content这里是插槽内容/view /my-card这三个口子基本就是组件的完整对外边界。如果你的组件实现里大量直接使用getApp()读全局变量或者直接调用wx.navigateTo跳转页面组件就开始和具体页面、具体业务环境产生隐性耦合。这样的组件换个页面复用可能会发现全局变量对不上、跳转目标不对最后变成“只能在这个页面用的组件”。我之前在团队里定过一条规矩组件内部不直接跳页面。组件需要“跳出去”的场景统一通过triggerEvent把事件抛给宿主页面由页面决定跳到哪里。这样组件就跟业务路由解耦同样一个商品卡片组件放在首页可以跳商品详情放在活动页可以跳活动详情组件的代码一行都不用改。3.2 样式隔离机制组件的类名不会污染页面页面的类名也进不去样式隔离是页面和组件之间另一个容易被忽视的关键差异。页面 wxss 是全局作用域页面里写一个.container类名页面范围内的节点都能命中。组件则默认开启样式隔离组件内部的类名不会渗透到页面页面的类名默认也不会渗透到组件内部。组件的样式隔离程度可以通过styleIsolation字段控制{ component: true, styleIsolation: isolated }取值含义如下取值效果isolated完全隔离组件内外样式互不影响apply-shared页面样式能影响组件但组件样式不影响页面shared页面和组件样式互相影响默认的isolated是最省心的方案。理解样式隔离之后很多“为什么样式没生效”的困惑都能迎刃而解。比如你在组件里精心定义了.card页面里恰好也有一个.card类名两者样式不会打架这正是隔离的意义。但也别得意太早隔离挡得住类选择器挡不住 CSS 的继承属性。页面设置了font-size、font-family、color这些有继承特性的属性时组件内部未显式设置的文字会直接继承宿主页面的值。做组件时如果想保证外观稳定最好在组件根节点上显式声明字体、字号、行高不要依赖继承。这不是小题大做而是在多页面复用组件时最容易发现的“玄学样式差异”。还有一处细节父页面给组件标签本身my-card写的样式作用在组件的宿主节点上这部分样式属于页面作用域组件内部根节点的样式属于组件作用域。两者看起来像是同一个元素实际上是两层节点。开发时如果把页面里的弹性布局意图写在组件内部根节点上经常会出现“外层容器明明设置了 display: flex但组件内部布局纹丝不动”的怪象。3.3 数据流向和 this 指向页面和组件里this的指代完全不同。页面 js 中this指向页面实例你可以直接调用页面生命周期、页面栈相关的接口组件 js 中this指向组件实例没有onLoad、onShow页面级接口在组件上下文里就不存在了。组件想要自己的“页面感”只能间接获取所在页面this.getPageId()可以拿到页面 idthis.triggerEvent可以把需要页面处理的事情交上去。数据流向的默认规则是单向的父页面通过properties向组件下发数据组件内部可以 setData 自己的数据但不能反向修改父页面的 data组件想通知页面改变数据只能通过事件上报由页面决定要不要改。这种单向数据流的设计是为了让数据变化的路径更可追踪。如果组件能直接改页面数据页面数据的变更来源就失控了排查问题时不知道哪个组件动过它。实际开发中最痛的一次经历是一个列表页放了大量自定义组件每个组件都自己从全局存储里读数据、自己更新全局存储。结果线上出现一个数据不同步的 bug排查时根本不知道是哪个组件在哪个时机改的全局数据最后只能全局搜索setStorageSync和getApp()调用点定位成本极高。后来重构时把所有全局数据的修改入口收敛到页面层组件只上报事件问题定位速度立刻提升了一个量级。4. 实践中最常踩的坑把页面逻辑塞进组件或反过来4.1 组件拿不到页面数据也别偷偷去拿最经典的错误心态是在组件内部写this.data.xxx以为能读到页面的 data。实际上组件内部的 data 是组件自己的独立数据域它天然看不到页面 data。数据想要进组件必须由页面通过properties显式传入并且组件内部不能直接修改properties的值。有些组件会在内部直接getApp()拿全局数据短时间看确实省事可一旦这个组件被另一个页面复用而那个页面的全局数据结构和当前页面不完全一致组件就会表现得很“神经质”——同一个组件在不同页面下行为不同查起来极其痛苦。更合理的做法是为组件定义清晰的对接口需要哪些数据、触发哪些事件、允许哪些插槽都写在组件文件顶部注释里。凡是契约之外的信息组件一律不主动碰。这样做虽然前期麻烦一点但组件换场景复用时的成本会直线下降。有一个技术细节也值得注意组件的properties可以设置observer属性每次变化时会触发监听回调。但如果你在监听回调里用了外部变量或者 setData 了组件内部数据要小心死循环。例如组件内部根据属性值变化更新 data再把更新的结果反馈给页面页面又改了属性传回来就会形成循环更新。规避办法是只在observer里做纯计算和组件内部状态更新不要向外触发事件除非你有明确的防重入控制。4.2 自定义事件的冒泡边界组件抛出的自定义事件默认情况下不会像原生事件那样一路冒泡到页面的任意层级。只有组件的直接宿主页面能通过bind:事件名监听到。组件内部还嵌套了子组件时子组件抛出的自定义事件默认只停在中间层组件不会自动穿透到页面。想让自定义事件冒泡得更远需要在triggerEvent时显式设置bubbles、composed、capturePhasethis.triggerEvent(cardtap, detailData, { bubbles: true, composed: true });这三个参数的含义分别是bubbles表示事件是否向节点树外层冒泡composed表示事件是否可以穿越组件边界即组件内外事件系统是否打通capturePhase表示是否支持捕获阶段监听。开发列表型页面时如果每一行都是一个组合组件行内还有子组件你希望点击任意位置都能由页面统一响应就必须按需开启bubbles和composed。这个坑最常见的迷惑点是“明明 bind 了事件为什么收不到”。排查时先看链路里中间组件是否重新抛出了事件再看triggerEvent的第三个参数有没有设置冒泡逻辑。有些人习惯在中层组件把事件原样this.triggerEvent再抛一次这也可以但要确保参数传递不丢字段。事件携带的detail对象最好按业务需要完整传递不要在每一层自己拼接否则嵌套层级深了以后detail 里的字段来源很难追溯。4.3 样式污染的那些隐藏通道样式隔离虽然能挡住类选择器的互相干扰但有两类“漏网之鱼”需要特别警惕。第一类是标签选择器。页面 wxss 里的button {}、view {}这类标签选择器可能绕过隔离规则影响组件内部节点。比如你在页面里写了一句button { border: none; }本意是去掉全站按钮的默认边框结果组件内部用到的button也一并变了。规避办法是组件内部控制结构的标签尽量少用裸标签选择器依赖直接写类名样式从根上减少被影响的概率。第二类是继承属性。字体、字重、行高、颜色、文本对齐这类属性天然向下继承页面设置了之后组件内部未显式声明的文本节点就会继承下来。跨页面复用组件时一个页面字体偏大、另一个页面颜色偏暗往往就是继承属性在作祟。我自己的做法是在组件的根节点写一份“最小化基样式”把font-size、line-height、color都显式声明一遍这样组件在任何页面表现都稳定不随宿主环境漂移。这三类坑在项目早期可能完全感受不到因为“页面和组件的类名不同碰不到一起”。但随着组件数量和页面数量上升标签选择器和继承属性带来的样式漂移会成为非常隐蔽的线上问题而且是那种“一个页面复现、另一个页面不复现”的诡异问题。能力范围内尽早做好组件样式隔离等于给未来省排查成本。5. 什么时候坚持用页面什么时候必须拆组件5.1 先问复用性这个块会在两个以上地方出现吗拆组件的第一个判断标准不是“代码超过一百行”也不是“感觉有点复杂”而是“这个块会不会在两个以上地方出现”。顶部导航、商品卡片、订单状态标签、空状态占位这类天然重复的块拆组件永远不亏。就算当前只有首页一个页面用它只要业务上确定多个页面都会出现早拆比晚拆省得多。反过来如果某个块具有强烈的“单页面专属”属性比如只有首页才有的大搜索框聚合区或者只有详情页才有的某个富文本展示区且未来没有任何其他页面会用到——那它就适合老老实实留在页面里。硬拆组件不会带来收益反而会引入额外的属性声明、事件传递、样式隔离调试的成本。每个组件多一道通信接口就多一分维护负担组件数量并不是越多越好。我自己的经验是做拆分判断时把“复用”具体化不是“感觉未来会复用”而是“现在已经有两个页面需要它”。靠感觉拆组件很容易拆出一堆只在一个页面里被引用一次的孤组件它们在文件系统里占据了组件目录的位置却并没有真正形成复用能力。这类组件多了之后组件目录反而变成一个没人敢删的垃圾场。5.2 性能与维护成本的权衡组件并非零成本。小程序框架对页面和组件做编译、渲染、更新时组件实例会带来额外的创建开销。尤其在列表场景里如果每个列表项都拆成一个组件每次setData更新列表数据都会触发组件树的 diff 和更新过程。列表项数量多、数据更新频繁时很容易出现卡顿、白屏闪烁甚至低端机上的渲染延迟。这引出一个很实际的问题列表项该不该拆组件我的建议是看列表项复杂度。如果一项里只有文字、图片、按钮结构简单优先用纯 wxml 模板循环甚至直接用block wx:for减少组件实例数量如果一项里有独立的交互逻辑、内部状态、嵌套结构拆组件的收益就会大于成本因为整项逻辑被独立出来页面 setData 时组件内部的状态不会被打散重算。维护成本同样重要。页面 js 操作业务数据比较直接组件 js 则要求更规范的数据流尤其是属性和事件接口要保持稳定。接口一旦设计得不合理后面每次需求变更都得同时改页面调用方和组件实现方等于双倍改动成本。所以拆组件时一定要在设计接口上多花半小时而不是先拆出来用再说。接口设计可以随时改实际上组件被多个页面引用后接口变更就会牵一发动全身尤其是有外部开发者或者跨团队复用时改动成本非常高。5.3 我日常坚持的拆分清单我现在做项目时基本遵循一条固定的判断路径不靠临场感觉而靠一个清单这个块是否已确认被两个以上页面复用是拆组件。这个块是否有独立的内部状态和交互逻辑是拆组件否则页面状态会越堆越重。这个块是否需要很强的页面级生命周期感知是留在页面里或者用页面通知组件的方式处理别让组件自己去猜。这个块是否会导致页面 wxml 超过几百行、可读性明显下降是拆一个模板或组件来整理结构。这个块如果拆成组件接口是否清晰可控犹豫不决时先保留在页面。这套清单不复杂但能挡住大部分“为了架构而架构”的过度拆分也能防止页面膨胀到无法维护。很多开发者纠结拆不拆本质上是想找一个“政治正确”的答案但工程上没有标准答案只有代价和收益的权衡。5.4 一个具体的拆组件样例假设我们要做一个“用户信息卡”需要展示头像、昵称、粉丝数点击后跳到个人主页。这个卡片在首页、搜索页、推荐页、活动页都会出现那拆成my-user-card组件是明确的。页面的使用方式非常干净my-user-card user-info{{userInfo}} bind:cardtapgoProfile /页面的事件处理函数负责路由跳转Page({ data: { userInfo: {} }, goProfile(event) { const { userId } event.detail; wx.navigateTo({ url: /pages/profile/profile?userId${userId} }); } })组件内部只管展示和点击反馈Component({ properties: { userInfo: { type: Object, value: {} } }, methods: { handleTap() { this.triggerEvent(cardtap, { userId: this.data.userInfo.id }); } } })组件不负责跳转不负责拉数据只负责“我被点击了告诉你卡片对应哪个用户”。页面则统一收集事件统一做路由统一管理数据来源。这样组件可以在任何需要展示用户信息的场景下复用而页面只保留自己真正该干的业务决策逻辑。反过来如果你把跳转逻辑写在组件内部那么“用户信息卡”组件就和“个人主页”这个具体页面绑定死了。未来想在小程序里增加一个“临时用户”卡片点击后不跳个人主页而是弹窗展示简介就会非常被动甚至得复制一个新的组件。关于边界我最后的真实感受写小程序久了会发现页面和组件的差异没有多玄妙核心就一句话页面是用户能直接打开的场景组件是被页面引用的积木。页面拥有一套和路由、窗口绑定紧密的生命周期和全局作用域组件拥有的是局部生命周期、局部作用域和更干净的通信用口。真正难的不是记住这些区别而是在实际项目里抵抗两种诱惑一种是懒得拆组件把一切逻辑都堆在页面里导致页面越来越大、越来越难维护另一种是盲目拆组件为了“结构好看”把一个页面大卸八块结果通信代码比原始逻辑还复杂。我个人后来养成一个很简单的工作习惯拿到需求先画页面草图然后圈出那些在两张以上草图上重复出现的区块它们就是组件候选再检查这些区块是否有自己独立的状态和交互再决定拆还是留。这套流程不需要高深理论但它在多个项目里帮我省掉了大量不必要的重构时间。如果你现在正为某个小程序项目的代码结构发愁不妨先按这个思路检查一遍页面里的重复区块往往第一个要拆的组件答案已经很明显了。
