MPX 是一个面向小程序场景的增强型跨端开发框架。它没有重新发明一套 DSL而是保留原生小程序的写法和工程结构再在此基础上补充状态管理、组件化、多端编译和性能优化能力。对于已经有微信小程序基础的开发者来说MPX 的上手成本很低对于需要同时维护多个小程序端的团队MPX 能把“一套代码多渠道发布”的成本控制在可接受范围内。这篇文章会围绕一条完整的主线展开先理解 MPX 的定位和工作原理然后从零创建一个项目写页面、组件和状态管理再构建到多个小程序平台最后处理性能问题和常见报错。读完以后你可以直接用这套思路搭建一个可运行、可扩展的小程序项目也能在遇到编译错误或跨端样式问题时快速定位方向。1. MPX 定位不是又一个跨端框架而是小程序的增强层1.1 为什么有了原生小程序还要用 MPX原生小程序本身已经具备页面、组件、路由、API 等完整能力但进入真实业务后几个问题会很快暴露出来第一小程序没有官方提供跨端复用方案。微信小程序、支付宝小程序、百度小程序、头条小程序虽然 API 相似但文件结构、生命周期、样式隔离、事件绑定都存在差异。如果每个端都单独维护一套代码需求变动时成本会成倍增加。第二原生语法缺少 Vue 风格的响应式能力。数据和视图的同步依赖开发者手动调用setData复杂页面中的数据流转、计算属性、监听器都要靠手工维护代码一多就很容易出现数据不同步的问题。第三组件化和状态管理的自由度不够。原生小程序虽然支持自定义组件但组件间通信在复杂场景下仍然繁琐全局状态没有统一方案。团队协作时每个人都有自己的数据管理习惯最终代码风格很难收敛。MPX 解决这些问题的思路是在原生小程序之上做增强。它保留了.wxml风格的模板、Page/Component的组件模型同时引入了 Vue 生态中已经被验证过的响应式状态管理、计算属性、侦听器、混合mixins等能力。开发者仍然可以写原生小程序代码也可以逐步把工程升级成 MPX 写法而不是必须一次性重构。1.2 MPX 和 Taro、uni-app、Remax 的差异市面上常见的跨端方案大致可以分为两类。一类是“编译时重写”代表是 Taro 3 之前的部分版本和 uni-app。这类框架会让开发者使用 React 或 Vue 语法编写代码然后在编译阶段转换成小程序原生代码。优点是开发体验统一缺点是当框架对原生小程序能力支持滞后时遇到不支持的 API 或性能瓶颈会比较难办。另一类是“运行时适配”代表是 Remax 和 Taro 3。这类框架在小程序运行时把 React/Vue 的虚拟 DOM 映射到小程序页面开发体验接近 Web但运行时层会增加一部分开销对小程序初始化性能有一定影响。MPX 走的是相对务实的第三条路增强原生。它在编译期分析模板把静态节点和动态绑定区分开尽量减少setData的数据量同时保留原生小程序组件的运行时行为。开发者可以直接使用wx:if、wx:for等原生指令也可以使用类 Vue 的能力。这种方式的下限更有保障即使 MPX 某个高级特性没有覆盖到你仍然可以退回原生写法不至于被框架卡住。1.3 MPX 的“增强”具体指哪些能力从工程视角看MPX 的核心能力可以整理成一张表能力原生小程序MPX数据响应式手动 setData支持基于响应式数据自动更新计算属性需要手动计算支持侦听器需要手动触发支持状态管理无官方统一方案支持 store多端编译无支持微信、支付宝、百度、字节等平台条件编译无支持组件间通信基础事件支持增强事件和 mixins性能优化开发者自己优化支持模板静态化、分包优化等这张表不是让你把原生小程序丢掉而是说明 MPX 在原生能力之上做了哪些补全。实际项目中你可以先用原生语法写一个页面再逐步引入 MPX 的状态管理和组件增强整个过程是渐进式的。2. 先把环境跑通创建项目、目录结构和构建命令2.1 安装 CLI 和创建项目MPX 官方提供了脚手架工具用于快速生成项目。使用前先确认电脑上已经安装了 Node.js 和 npm/yarn。Node.js 版本建议使用长期支持版本如果你的电脑上安装了多个 Node.js 版本建议先用nvm切换到指定版本避免后续依赖安装时报错。安装脚手架并创建项目的常见命令如下npm install -g mpxjs/cli mpx create my-mpx-project如果你的项目需要指定模板CLI 通常会提供交互式选项。没有特殊需求时选择默认模板即可。创建完成后进入项目目录并安装依赖cd my-mpx-project npm install这里要注意MPX 的脚手架版本和核心依赖版本存在对应关系。如果你创建项目后运行npm install报错先确认 npm 源是否可用再检查 Node.js 版本是否满足项目要求。不要把报错直接归因于框架本身。2.2 项目目录结构与核心文件作用执行完创建命令后项目里一般会生成类似下面的目录src/ pages/ index/ index.mpx app.mpx app.json app.js store/ public/ project.config.json package.jsonsrc目录是源码目录app.mpx是小程序入口文件它包含了全局配置、全局样式和 App 生命周期逻辑。app.json是小程序全局配置比如页面路由、窗口表现、分包结构等。页面文件后缀是.mpx一个文件内部可以包含template、script、style三个部分写法上类似 Vue 单文件组件。例如template view classhello text{{ message }}/text /view /template script import { createPage } from mpxjs/core createPage({ data: { message: Hello MPX } }) /script style langscss .hello { padding: 20px; } /style这个文件最终会被 MPX 编译成对应小程序平台可识别的页面文件。对于微信小程序编译后会在dist/wx目录下生成index.js、index.wxml、index.wxss、index.json。2.3 理解构建脚本与目标端模式MPX 项目在package.json中会暴露多个构建命令。常见的脚本名是{ scripts: { serve: mpx-cli-service serve --mode wx, build:wx: mpx-cli-service build --mode wx, build:ali: mpx-cli-service build --mode ali, build:baidu: mpx-cli-service build --mode baidu, build:tt: mpx-cli-service build --mode tt } }其中--mode wx表示构建目标为微信小程序ali对应支付宝小程序baidu对应百度小程序tt对应字节小程序。具体脚本名以你创建的项目为准但思路是一样的MPX 通过mode参数决定编译产物写入哪个平台目录。本地开发一般使用npm run serve默认serve命令会启动开发模式并在文件变更时自动重新编译。编译后的目录在你指定的模式所对应的目录中比如dist/wx。微信小程序开发工具导入这个目录就能看到真实运行效果。2.4 启动开发者工具完成首次预览以微信小程序为例首次预览步骤如下。打开微信开发者工具选择“导入项目”目录选择项目根目录下的dist/wxAppID 可以先使用测试号。导入后等待编译完成如果项目根目录存在project.config.json开发者工具会读取其中的miniprogramRoot配置自动定位到正确目录。如果预览时页面空白最优先检查的不是代码而是dist/wx目录是否存在以及开发者工具导入的目录到底对不对。很多新手会误把项目根目录当成小程序的代码目录导入导致开发者工具无法识别app.json。注意开发阶段每次修改源码后都要确认是否已经重新编译特别是从远程仓库拉取新代码后不要直接打开旧编译目录立即报错。3. 页面和组件开发直接沿用原生语法再叠加增强语法3.1 数据绑定、列表渲染和事件处理MPX 的模板语法与原生小程序基本一致所以原生小程序开发者可以直接上手。在.mpx文件的template中数据绑定使用双花括号列表渲染使用wx:for条件渲染使用wx:if。一个简单的商品列表页面template view classgoods-list view wx:for{{goodsList}} wx:keyid classgoods-item text{{ item.name }}/text text{{ item.price }}/text button bindtaponBuy>import { createPage } from mpxjs/core createPage({ data: { price: 100, count: 2 }, computed: { total() { return this.price * this.count } } })在模板中可以直接引用totalview{{ total }}/view当price或count发生变化时total会自动重新计算不需要手动调用setData。侦听器用于监听一个字段的变化适合做表单联动或异步搜索createPage({ data: { keyword: }, watch: { keyword(val, oldVal) { console.log(keyword changed:, oldVal, -, val) this.search(val) } }, methods: { search(keyword) { // 执行搜索逻辑 } } })计算属性和侦听器确实能减少很多样板代码但不要因此把所有逻辑都塞进去。计算属性应该保持无副作用侦听器里不要执行太重的同步操作否则页面渲染和事件响应都会受影响。3.3 自定义组件的写法与数据传递MPX 中的自定义组件同样使用.mpx文件对外暴露属性对内维护自己的状态。一个简单的计数器组件!-- components/counter.mpx -- template view text{{ value }}/text button bindtaponIncrement1/button /view /template script import { createComponent } from mpxjs/core createComponent({ properties: { value: { type: Number, value: 0 } }, methods: { onIncrement() { this.triggerEvent(increment, { value: this.value 1 }) } } }) /script在页面里引用组件时需要先在app.json或页面 JSON 中注册组件路径。如果你使用的是 MPX 的增强能力也可以直接在页面模板中通过 import 方式引入具体写法以项目模板配置为准。父页面接收子组件事件时使用bind:incrementcounter value{{currentValue}} bind:incrementonIncrement /组件化的价值在于隔离和复用。建议一个组件只负责一个明确功能不要在组件内部直接修改父级传入的value而是通过事件告知父级修改。这样数据流清晰排查问题时也更简单。3.4 条件编译让同一份代码适配多端差异多端项目中不同平台的 API、组件、样式都会有小差异。MPX 提供了条件编译能力可以在源码中标记哪段代码只属于某个平台。模板中的条件编译写法!-- #ifdef MP-WEIXIN -- view只在微信小程序中渲染/view !-- #endif -- !-- #ifndef MP-WEIXIN -- view除了微信小程序之外渲染/view !-- #endif --JS 中的条件编译写法// #ifdef MP-ALIPAY console.log(支付宝小程序环境) // #endif样式中的条件编译/* #ifdef MP-WEIXIN */ .hint { color: #ff6f00; } /* #endif */条件编译要谨慎使用。合理场景是某平台只支持一个特殊 API或者某个 UI 表现有明显差异。滥用条件编译会让代码在多个平台之间出现分叉维护成本反而上升。建议把差异收敛到独立模块中页面上尽量少出现平台分支。4. 状态管理和内置能力复杂业务下的组织形式4.1 状态管理要解决什么问题小程序页面之间是路由隔离的页面间的共享数据通常需要通过跳转参数、全局变量或存储来传递。业务简单时问题不大但一旦涉及登录信息、购物车、用户偏好、多页面联动就会面临两个麻烦一是数据来源不统一。每个页面都要从接口或存储中读取数据并且要保持同步很容易出现 A 页面修改了数据B 页面还是旧数据。二是更新链路不清晰。数据发生变化时所有依赖它的页面都应该被通知但原生小程序没有现成的机制。MPX 提供了createStore来管理全局状态。它采用类似 Vuex 的结构把状态放在state中通过mutations同步修改通过actions处理异步逻辑。这样数据变更的链路有迹可循。4.2 Store 的定义与使用创建一个 store 文件例如src/store/index.jsimport { createStore } from mpxjs/core const store createStore({ state: { userInfo: null, count: 0 }, getters: { isLogin(state) { return !!state.userInfo } }, mutations: { setUserInfo(state, userInfo) { state.userInfo userInfo }, increment(state, amount 1) { state.count amount } }, actions: { async login(ctx, payload) { const userInfo await fetchUser(payload) ctx.commit(setUserInfo, userInfo) return userInfo } } }) export default storegetters相当于 store 的计算属性mutations是唯一允许修改state的地方actions内部可以执行异步操作最后提交 mutation。页面或组件中可以通过this.$store访问 store 实例import { createPage } from mpxjs/core createPage({ computed: { isLogin() { return this.$store.getters.isLogin } }, methods: { onLogin() { this.$store.dispatch(login, { username: admin, password: 123456 }) } } })模板中也可以直接引用view wx:if{{ isLogin }}已登录/view view wx:else未登录/view4.3 页面间通信和全局数据同步多个页面同时消费 store 里的同一个状态时只要页面通过计算属性访问状态变更后页面会自动更新。这解决了全局数据同步的问题。但要注意一个常见错误不要在页面里直接修改store.state中的对象比如写this.$store.state.userInfo xxx。这样虽然能生效但会让数据变更难以追踪。推荐做法是定义对应的 mutation通过commit触发。如果页面和组件之间需要传递复杂数据优先使用组件属性加事件而不是直接把每个页面都塞进 store。只有跨页面共享的数据才应该放 store。4.4 常用内置能力请求、路由、存储MPX 没有强行封装所有 API而是提供了一些实用工具。比如mpx.request可以在多个平台统一发起网络请求import mpx from mpxjs/core mpx.request({ url: https://api.example.com/goods, method: GET, data: { page: 1 } }).then(res { console.log(res.data) }).catch(err { console.error(err) })路由能力通常仍依赖各小程序平台的原生 API比如wx.navigateTo在支付宝小程序中对应my.navigateTo。MPX 可以通过条件编译或统一封装来解决建议团队内部封装一个navigateTo工具函数把平台差异收敛到一个文件里。本地存储可以使用平台的 Storage API也可以封装一层storage工具。缓存 key 的命名要规范避免不同业务之间互相覆盖。例如统一前缀mpx_并加上业务模块名。5. 多端构建的细节从微信到支付宝、百度、字节5.1 一个项目构建多种小程序MPX 的多端构建过程可以理解为“一次编译多端产出”。编译时根据mode参数生成对应平台的小程序代码。常见脚本npm run build:wx npm run build:ali npm run build:baidu npm run build:tt每次构建后检查对应dist目录。微信在dist/wx支付宝在dist/ali。然后把对应目录导入到各平台的开发者工具中。开发环境和生产环境的区别也比较明显项目开发环境生产环境构建模式开发模式保留 sourcemap生产模式压缩代码环境变量使用.env.development使用.env.production接口地址本地或测试环境线上环境域名校验开发者工具可关闭必须配置合法域名日志输出保留 console按需移除或上报生产构建前一定要检查接口地址、AppID、分包配置和域名白名单避免把测试环境配置发布上线。5.2 不同端的差异点与适配写法虽然 MPX 会处理大部分编译差异但仍有几个地方需要开发者自己处理第一页面生命周期和 API 差异。微信小程序的onPullDownRefresh、onReachBottom在支付宝小程序中可能对应不同名称或不同行为。MPX 通常会把通用生命周期做映射但业务上对刷新、加载更多的处理逻辑仍然需要验证。第二组件标签差异。比如微信中的button在支付宝中仍然存在但open-type的能力范围不同。涉及登录、支付等原生能力时要分别查看各平台文档。第三样式兼容性。各小程序平台的基础样式不完全一致字体大小、边框、圆角、scroll-view 行为都可能不同。建议在公共样式中统一重置涉及平台特有样式时使用条件编译。第四存储和网络能力。不同平台的 storage 容量、同步异步 API 可能有差异网络请求的 header 限制、超时设置也不一致。建议封装统一的 storage 和 request 模块。一个稳妥的做法是先以微信小程序为主完成开发再逐个平台验证。条件编译覆盖的平台差异要记录在项目文档中避免后续开发人员不知道某个分支为什么存在。5.3 构建产物如何验证多端项目不能只看微信端跑通就认为全部端都正常。每个平台都要做一轮基础验证。验证清单可以这样设计验证项微信支付宝百度字节项目能正常编译是是是是页面能正常打开是是是是登录流程正常是是是是支付流程正常是是是是网络请求正常是是是是分享功能正常是是是是关键页面样式一致是是是是不要等到发版前才去验证多端。建议在开发早期每完成一个功能模块就在所有目标平台上跑一遍基础流程越早发现适配问题修改成本越低。5.4 多端输出时的常见陷阱一个很容易踩的坑是直接使用平台专有 API 而没有做兼容。比如wx.getUserProfile在非微信平台不存在运行时会直接报错。解决办法是把平台 API 调用封装成公共函数内部使用条件编译或运行时能力判断。另一个坑是构建产物目录不一致。团队成员可能在本地构建出了不同平台的目录提交代码时如果误提交dist目录会产生大量冲突。推荐在.gitignore中忽略所有dist目录。还有一个坑是资源引用路径。多端构建后图片、字体等静态资源的路径可能会被改写。如果某个平台出现图片加载失败优先检查构建后 JSON 和 WXML 中的路径而不是直接在源码中找问题。6. 性能和工程化真实项目里更容易踩坑的部分6.1 模板静态化和渲染性能小程序性能瓶颈通常集中在首屏渲染和频繁setData。MPX 在编译阶段会尝试把模板中的静态部分标记出来减少小程序运行时的 diff 范围。对开发者来说需要关注动态绑定的粒度。以下写法会在数据更新时带来更多开销view{{ user.name }} - {{ user.age }} - {{ user.address.city }}/view如果只有user.name会变化其余字段不参与渲染建议把模板拆细让每个动态绑定范围更小或者使用计算属性缓存。另一个常见做法是避免在模板中直接调用方法text{{ formatTime(item.createTime) }}/text每次渲染都会重新执行formatTime。如果列表很长性能会明显下降。建议在数据源进入页面时先完成格式化模板只负责展示。6.2 分包、按需加载和资源体积小程序包体积有限制MPX 项目同样需要做好分包。把独立业务模块拆成分包登录页、首页等核心页面放在主包低频页面放在分包。MPX 的分包配置与原生小程序类似在app.json中配置subpackages字段。编译时MPX 会根据入口文件依赖关系尽量把只被分包引用的代码和资源打进对应分包。静态资源也要控制体积。图片优先使用压缩后的资源能放到 CDN 的不要打到包里。代码中建议开启压缩并对公共模块做合理的 tree shaking。如果构建后包体积仍然很大可以用构建工具分析依赖定位是哪个模块引入了大量代码。6.3 图片、接口缓存和启动耗时首屏加载时图片往往是最大瓶颈。建议采用以下策略首屏只加载必要的图片非首屏图片使用懒加载。使用 CDN 且图片格式尽量采用压缩率更高的格式。对图片设置合理的宽高避免小程序根据实际尺寸反复计算。小图标可以合并成雪碧图或者使用 base64 内嵌在样式中。接口请求方面对不经常变化的数据要设置缓存。可以使用 storage 做简单缓存但要注意缓存过期策略。比如每次请求前先判断缓存时间超过五分钟就重新拉取。启动耗时还和 JS 逻辑执行有关。不要在 App 的onLaunch中执行太多同步操作尽量延迟非关键的初始化逻辑。第三方 SDK 的初始化也应该错峰执行避免阻塞首屏。6.4 代码规范与可维护性清单MPX 项目在多人协作时建议维护一份可执行清单核心内容包括检查项要求页面文件职责一个页面只负责一个路由场景组件设计组件不直接修改 props通过事件通信store 使用全局状态必须走 mutation不直接修改 state条件编译平台差异集中到独立模块页面中少用分支API 调用统一封装 request 和 storage禁止页面散落平台 API包体积定期检查主包和分包体积错误处理接口失败要给出统一提示不能静默失败日志console 日志带业务模块前缀方便线上过滤这些规范不需要一次性强制执行但建议在代码审查时逐项检查。项目越大这类工程约束越能降低返工成本。7. 常见问题排查配置、编译、白屏、适配问题7.1 编译期报错现象执行npm run serve或npm run build:wx时终端抛出类似Module not found: Cant resolve mpxjs/webpack-plugin的异常。可能原因依赖没有安装完整node_modules缺失。安装依赖时使用了不同的包管理器锁文件不一致。Node.js 版本和当前 MPX 版本不兼容。检查方式npm ls mpxjs/webpack-plugin node -v处理建议删除node_modules和package-lock.json或yarn.lock重新执行npm install。如果仍然报错检查项目模板要求的 Node.js 版本并通过nvm切换。7.2 开发阶段页面白屏现象微信开发者工具能打开项目但页面空白控制台提示Page is not found或Component is not found。常见原因编译产物不是最新代码开发者工具加载的是旧目录。app.json中注册的页面路径与真实文件路径不一致。页面 JS 执行错误生命周期函数或数据初始化抛异常。处理顺序确认执行的是正确的构建命令检查dist目录最后修改时间。打开开发者工具的“编译模式”为普通编译重新编译。查看 Console 中的错误堆栈优先定位 JS 异常。检查dist/wx/app.json中的 pages 字段和相关页面文件是否真实存在。建议在源码入口处加一个简单的生命周期日志确认页面确实执行了onLoadonLoad() { console.log([page-index] onLoad) }日志能打印就说明路由正常问题多半在数据请求或渲染阶段。7.3 条件编译不生效现象在template或 JS 中写了#ifdef MP-WEIXIN但构建到微信端时被标记为其他端的代码仍然出现。可能原因条件编译注释写在了错误位置。目标端标识名写错比如把MP-WEIXIN写成了MP-WECHAT但项目配置里使用的标识并不相同。代码被某个插件或其他编译工具提前处理注释被移除。检查方式grep -rn MP-WEIXIN src运行后看注释关键字是否存在于源码中以及关键字大小写是否正确。然后检查构建产物grep -rn 只在支付宝端渲染 dist/wx如果dist/wx中仍存在该文本说明条件编译没有被正确识别。处理建议参考当前项目脚手架内置的.mpx模板写法确认官方使用的条件注释格式。不要凭记忆使用可能错误的注释格式。7.4 多端构建产物差异现象同样一段样式在微信端正常在支付宝端错位。可能原因不同平台对 CSS 属性支持不一致。默认样式不同比如button在微信和支付宝中按钮边框存在差异。使用了平台特有布局属性没有在目标平台做兼容。处理建议先用开发者工具的样式面板比较两个端点计算样式优先修复默认样式差异。可以统一引入一个reset样式在公共样式里重置button、view text等标签的默认间距。对于真正无法统一的差异使用条件编译把差异样式单独写在对应平台分支中。最后一定要在真实设备或开发者工具的多端模拟环境中验证不能只改源码不验证产物。7.5 错误排查速查表问题现象常见原因检查方式处理建议编译报 Module not found依赖缺失或版本不匹配npm ls 检查依赖重装依赖确认 Node 版本页面白屏路由或 JS 异常查看 app.json 和 console修复页面路径或 JS 异常接口请求失败域名未配置或网络异常开发者工具关闭域名校验配置合法域名或使用测试环境图片加载失败路径错误查看构建产物中的资源路径修正静态资源引用方式条件编译不生效注释格式或标识错误grep 关键字按官方格式重写setData 数据量过大模板中绑定数据过多分析页面渲染数据拆分模板、减少动态绑定多端样式错位平台默认样式差异样式面板对比使用 reset 样式加条件编译8. 从学习到生产扩展方向和练习建议8.1 当前项目可以继续深入的方向完成一个基础 MPX 项目后你可以沿着以下方向深入第一深入学习编译器原理。了解 MPX 如何把.mpx文件转换成各平台小程序代码为什么模板静态化能提升性能这能帮助你在遇到诡异编译问题时更快定位。第二研究插件和自定义构建能力。MPX 支持在构建流程中扩展自定义能力。如果你的团队有特殊需求比如生成独立的 UI 组件包、自动上传 sourcemap、多语言切换可以通过自定义构建插件实现。第三建立组件库。把业务中的通用组件逐步沉淀成内部组件库并不一定需要完全抽象成公共库可以先从项目内的components目录规范开始再逐步抽离。第四结合小程序云开发或自建后端。将登录、权限、支付、数据存储与 MPX 项目打通形成完整业务闭环。8.2 发布前的检查清单上线前建议逐项确认检查项是否完成生产环境接口地址已配置是微信小程序合法域名已配置是多端构建产物均已导入对应平台验证是主包体积满足平台限制是分包路由和页面路径正确是登录、支付、分享等关键流程通过是错误提示文案统一且无敏感信息是console 日志已清理或按需保留是版本号和 changelog 已更新是灰度发布和回滚方案已确认是发布不是把代码上传到平台后台就结束。实际线上环境出现问题时你还需要能快速定位。因此建议在项目中集成错误上报和日志采集至少要在关键操作和异常分支中埋点。8.3 新手最容易忽略的三件事第一件是“不要只学框架不学原生”。MPX 是基于原生小程序增强的很多问题最终都要回到原生小程序的能力边界去判断。遇到模板渲染异常或组件更新失败时原生小程序的调试工具、生命周期日志、setData数据量检查仍然是最可靠的排查路径。第二件是“不要一开始就强行封装”。项目初期为了快速验证业务直接使用原生写法没有问题。等到业务复杂度上来了再逐步引入 store、组件集中管理、多端条件编译。过早抽象会带来大量无谓的架构代码反而不利于项目演进。第三件是“不要把多端当成万能”。跨端方案解决的是大部分通用场景但小程序平台的支付、登录、分享、地图等能力仍然需要各平台单独适配。多端是降低维护成本的手段不是消除平台差异的魔法。学习 MPX 最有效的方式是拿一个真实的小业务去练手比如一个带登录、商品列表、购物车和订单页面的电商 Demo。在这个小项目中把页面、组件、store、请求封装、多端构建完整跑通你就能理解 MPX 的每一个能力应该在什么场景使用以及哪些地方需要继续保持原生写法。这样进入生产项目时你看到的就不再是零散的 API而是一条清晰的技术链路。