背景
刚接触小程序工程时，很多人会先听到 Taro。它的吸引力很直接：用接近 React 或 Vue 的现代前端方式写业务，再编译到微信小程序、H5、支付宝小程序等目标端。
但只知道 Taro 还不够。真正做技术选型时，问题通常不是“有没有框架”，而是“团队现有技术栈、目标端范围、性能要求和后续维护成本分别是什么”。这次整理的目标，就是把 Taro 放回小程序工程的大图里，再看还有哪些类似框架可以选择。
这次解决了什么
这次先把 Taro 小程序工程的基本形态说清楚：它通常包含 config、src/app.config.ts、src/pages、公共组件、接口封装、状态管理和编译产物目录。开发者写的是现代前端组件，最终由 Taro 编译成小程序能够识别的页面、组件和配置。
在这个基础上，又补了一张选型地图：
uni-app：偏 Vue 生态，适合同时做小程序、H5、App。Mpx：更贴近小程序原生模型，适合性能敏感、以小程序为主的复杂项目。Remax：偏 React 风格，适合希望用 React 方式开发小程序的团队。kbone：偏 Web 到微信小程序的同构迁移方案。Chameleon：跨端 DSL 方案，更适合已有历史项目或研究型场景。WePY、mpvue：早期小程序工程化框架，现在更多用于维护存量项目。
这样一来，选型就不是记框架名字，而是按项目条件做取舍。
关键过程
先看 Taro。Taro 的核心价值是把 React、Vue 等生态里的组件化、工程化、状态管理、构建流程带到小程序开发里。对熟悉现代前端的团队来说，它降低了从 Web 进入小程序的成本，也方便一套代码尝试多端输出。
再看 uni-app。它是 Vue 技术栈里非常常见的跨端方案，配套生态完整，文档、插件市场、工具链和 App 端能力都比较成熟。如果项目明确要同时覆盖小程序、H5 和 App，且团队偏 Vue，uni-app 通常会进入优先评估列表。
Mpx 的气质不太一样。它不是把 Web 框架完整搬进小程序，而是在小程序原生规范上增强响应式、组件化和工程化能力。对“主要就是做小程序，而且性能、包体积、原生兼容很重要”的项目来说，Mpx 往往比纯粹追求跨端抽象更稳。
Remax 更适合 React 心智。它强调用 React 的组件、Hooks、TypeScript 体验去写小程序。这个方向对 React 团队友好，但新项目仍要看维护活跃度、生态配套和团队是否愿意承担框架热度变化带来的风险。
kbone 解决的是另一个问题：已有 Web 项目希望尽量复用代码进入微信小程序。它适合迁移和同构场景，不一定适合作为所有新小程序项目的默认选择。
最后是历史框架。WePY 和 mpvue 都曾经是小程序工程化的重要代表，但今天更多应该放在“维护老项目”的位置，而不是新项目首选。
踩坑
第一个坑，是把“跨端”理解成“完全不用关心平台差异”。无论 Taro 还是 uni-app，只要目标端里包含小程序，就必须面对平台 API、组件能力、包体积、权限、生命周期、审核规则和运行时差异。框架能统一一部分写法，但不能消除所有平台边界。
第二个坑，是只按团队喜好选框架。熟悉 React 就上 Taro，熟悉 Vue 就上 uni-app，这个判断虽然有用，但还不完整。还要看目标端是否包含 App、项目是否性能敏感、是否已有原生小程序资产、是否需要长期维护，以及框架生态是否足够稳定。
第三个坑，是新项目误选历史框架。WePY、mpvue 这些名字仍然会在搜索结果和旧项目里出现，但它们更适合存量维护。新项目如果没有强约束，通常应该优先看 Taro、uni-app、Mpx 这类仍在主流使用和维护的方案。
最后方案
可以用这套简单规则做初筛：
- 团队熟悉 React，要做小程序或多端前端，优先评估
Taro。 - 团队熟悉 Vue，并且目标包括小程序、H5、App，优先评估
uni-app。 - 项目以小程序为主，复杂度高、性能敏感、希望贴近原生，重点评估
Mpx。 - React 团队只想要小程序开发体验，也可以评估
Remax，但要额外确认维护状态。 - 已有 Web 项目想迁移到微信小程序，可以单独评估
kbone。 - 已有老项目使用
WePY、mpvue，以维护和迁移评估为主，新项目一般不优先选择。
如果只能给一个最实用的结论：新项目通常先在 Taro、uni-app、Mpx 里做选择。它们分别对应 React 跨端、Vue 多端和小程序原生增强这三条主线。
以后怎么做
以后遇到小程序框架选型，可以先问五个问题：
- 团队主技术栈是 React 还是 Vue？
- 目标端只是微信小程序，还是还要 H5、App、其他小程序？
- 项目是从零开始，还是已有 Web 或原生小程序要迁移？
- 性能、包体积、原生组件兼容是否是核心要求？
- 这个框架的维护活跃度、组件生态、调试体验和团队招聘成本是否可接受？
回答完这些问题，再看框架名字，判断会清楚很多。框架不是越“跨端”越好，而是越贴近项目真实约束越好。