如果你在 uni-app 社区里泡过一段时间大概率会刷到这两个名字一个叫meng-xi/create-uni-app另一个叫unibest。我第一次看到它们的时候也愣过一下——不都是帮我创建一个 uni-app 项目的工具吗一个叫脚手架一个叫框架到底哪里不一样后来我把两个都实际跑了一遍又分别用在几个不同类型的项目里才慢慢琢磨明白这根本不是“谁比谁好用”的问题而是两条完全不同的工程路线。一个倾向于“帮你把项目生出来之后你自己做主”另一个则倾向于“给你一套完整的架构约定你在这个框架里开发”。如果你正在纠结选哪个或者在团队里负责技术选型这篇文章把我自己的实测感受和判断逻辑完整写给你。1. 两个项目分别是什么一场“各回各家”的路线分岔1.1 脚手架帮你把项目生出来然后功成身退meng-xi/create-uni-app本质上就是一个初始化工具或者说是一个“项目生成器”。它的核心作用就一句话通过一条命令把一套已经配置好的 uni-app 项目模板下载到你本地顺便帮你装好依赖、准备好开发环境。你在命令行里执行它它会问你几个问题项目名叫什么要 TypeScript 还是 JavaScript要不要 Vue3需不需要 pinia回答完之后一个能直接npm run dev:mp-weixin跑起来的项目就出现了。这个定位其实跟前端社区里常见的create-vite、create-next-app是同一类东西。它们的设计哲学是初始化完成的那一刻工具的使命就结束了。脚手架不会在运行时介入你的业务代码不会强制你使用某个目录结构更不会在你写页面的时候蹦出来指手画脚。它给你的是一个“起点”而不是一个“框架”。1.2 重型框架把工程化方案一起打包进来就得按规矩来unibest则完全是另一个物种。它不是一个初始化工具而是一套基于 uni-app 的完整开发框架。你用它创建项目后得到的不仅仅是一个“能跑的 uni-app 项目”而是一个已经把请求封装、状态管理、路由拦截、样式方案、代码规范、构建优化全都配好了的工程体系。换句话说unibest把“一个成熟团队在项目启动前要做的大部分工程化决策”提前替你做了。在unibest的体系里你写业务代码的方式是被框架塑造的。比如页面放在哪个目录、请求函数怎么写、全局状态走什么通道、样式用原子类还是 scss 变量这些都有明确约定。好处是你不需要从零思考这些问题坏处是你必须花时间学习和遵守这些约定。用一句大白话说脚手架帮你把房子地基打好就撤了框架则是把整栋楼的结构、水电、装修风格都设计好让你直接往里面摆家具。这两种路径没有绝对优劣但它们对使用者、使用场景、长期维护成本的影响天差地别。把这两个东西放在一起对比本质上是在问一个更深层的问题你的项目到底需要一个“起点”还是需要一个“操作系统”这个问题想清楚了选型就完成了一大半。2. create-uni-app 的“轻”命令执行完剩下的都是你的自由2.1 一条命令走完的初始化流程先看你实际用的时候会发生什么。meng-xi/create-uni-app的常见用法是# 使用 npm npm create meng-xi/uni-app my-project # 使用 pnpm pnpm create meng-xi/uni-app my-project执行之后终端会进入交互式问答一般会问这些项目名称如果命令里已经传了这步可跳过选择 Vue 版本Vue3 是默认推荐Vue2 基本不再建议新项目用是否使用 TypeScript是否需要 pinia / vuex是否需要 uni-ui 等组件库回答完之后它会把对应模板拷贝到当前目录然后自动执行依赖安装。整个过程通常在1到3分钟内结束你获得的是一个干干净净、没有任何额外封装的 uni-app 项目。目录结构大致长这样my-project/ ├── src/ │ ├── pages/ │ │ └── index/ │ │ ├── index.vue │ │ ├── index.scss │ │ └── index.config.ts │ ├── static/ │ ├── App.vue │ ├── main.ts │ ├── manifest.json │ └── pages.json ├── package.json ├── tsconfig.json ├── vite.config.ts └── .gitignore没有多余的stores目录、没有api目录、没有封装好的request.ts。这不是缺点而是它的设计目标把选择权还给你。对于一个小程序/H5/App 都要做的项目你可以完全按照自己团队的习惯去搭状态管理、配请求层、设计目录规范。脚手架不会以任何形式限制你。2.2 轻在哪里无侵入、无锁定、无隐藏约定这是我实际用了几个项目之后体会最深的三个特点。无侵入的意思是脚手架在项目运行时不产生任何“存在感”。你写代码的时候不会感觉到“哦我这是在一个脚手架生成的项目里”因为所有代码都是普通 uni-app 语法没有任何特殊运行时逻辑。这一点对新手特别友好——你学到的所有 uni-app 知识都能直接复用不会被工具本身的抽象概念干扰。无锁定意味着你随时可以对项目做任何改造。想换构建工具想加代码生成器想把目录改成features模式都行。脚手架没有在你和 uni-app 之间加任何一层所以你不会被任何“框架层面的设计”绑架。对于喜欢精细控制工程的团队来说这种自由是刚需。无隐藏约定是我最看重的一点。有些框架会在背后做很多“魔法操作”比如自动注册路由、自动扫描某个目录下的文件、自动注入依赖。听起来很爽但当项目出问题的时候你往往要花很长时间去排查这些“魔法”具体干了什么。create-uni-app生成的项目则非常简单直白main.ts里注册了啥就是啥pages.json里写了什么页面就有什么页面逻辑链路完全可追溯。2.3 轻量方案的边界什么场景下会露怯不过轻量不是没有代价。当你的项目发展到一定程度纯粹的手工配置会逐渐变成负担。我自己遇到过的几个真实场景新成员加入团队时需要花时间解释“我们的请求封装放在哪里”“api 接口怎么统一管理”“全局状态什么时候走 pinia”。脚手架本身不提供任何规范这些全部依赖团队内部的文档和文化。代码规范保持一致很难。每个人写页面的习惯不同有的人把逻辑全塞进 setup 里有的人喜欢抽 composable如果没有强约束代码风格会越来越乱。常见的工程能力需要自己逐一补齐。比如请求拦截器、错误码统一处理、登录态过期刷新、权限指令、主题定制……这些在大型框架里往往是现成的但在脚手架项目里都需要自己写或者自己找库。所以我的结论是对于 1~3 个人、业务逻辑以页面展示为主、生命周期在半年到一年的项目脚手架是完全够用的。但如果你预感到项目会持续迭代两年以上参与的人会变多业务会越来越复杂那纯粹靠脚手架起步后面大概率要补很多工程化功课。3. unibest 的“重”不是代码量大而是替你决策了所有关键路径3.1 开箱即用的一整套工程约定unibest这类重型框架最大的特点是它把从前端工程化实践中沉淀下来的最佳实践直接固化进了项目模板里。用unibest创建出来的项目目录结构和脚手架生成的相比差距一眼就能看出来my-unibest-app/ ├── src/ │ ├── pages/ │ ├── components/ │ ├── stores/ │ ├── api/ │ ├── utils/ │ ├── styles/ │ ├── static/ │ ├── App.vue │ ├── main.ts │ ├── manifest.json │ └── pages.json ├── .vscode/ ├── .husky/ ├── .eslintrc.json ├── .prettierrc.json ├── unocss.config.ts ├── package.json └── vite.config.ts看到这些目录和配置文件你应该能感受到差别stores、api、styles、utils是已经替你规划好的模块划分.husky、.eslintrc.json、.prettierrc.json表明代码规范在项目创建第一天就是强制的unocss.config.ts则说明原子化 CSS 方案已经内置。更关键的是unibest不只是“有这些目录”它还把对应的能力真正封装好了。比如请求层它通常会封装基于uni.request的统一请求工具帮你处理 baseURL 配置、token 携带、错误码拦截、超时重试状态管理层面它默认集成 pinia 并给出模块化的推荐写法路由拦截、登录态管理也会提供一层现成的方案。你拿到项目后不需要再搜“uni-app 怎么封装请求”直接往api目录里加接口函数就能干活。3.2 重型框架对团队的隐性收益不是代码量是决策成本很多人不理解为什么有人愿意“自废武功”选择这种约束性强的框架觉得“限制太多了不自由”。但如果你带过 5 人以上的前端团队你会明白一个更现实的道理团队最大的成本不是编码而是沟通和决策。“请求到底放在哪个目录”“错误码在哪里统一处理”“同事写的页面为什么不遵循我们的 prettier 规则”“新来的同学问我不清楚项目结构怎么办”——这些问题在脚手架项目里每一个都会真实发生而且每一个都要你花时间回答、盯代码、做 Code Review。而在unibest体系里这些问题在项目初始化时就已经有了标准答案目录规定好了、规范内置了、封装写好了。它真正的价值在于框架把“工程治理”这件事从人的自律变成了结构的强制。你不需要靠团队文档来提醒别人“记得放 api 目录”因为项目结构本身就引导你这么做你不需要一遍遍强调代码规范因为 commit 之前就有 lint-staged 卡住你。这是重型框架对组织效率的隐性提升短期内感受不到但三个月后回头看差异非常明显。3.3 重的代价学习曲线与升级风险但“重”绝对不是免费的。我第一个用unibest的项目光“读懂这个框架在干嘛”就花了两三天。你需要理解的不只是 uni-app 本身还有框架作者对工程化的理解为什么这么分层为什么用 UnoCSS 而不是 scss为什么 store 要这么组织这些设计有它自己的逻辑但如果你不认同使用过程会非常难受。还有升级风险。unibest这类框架往往跟 uni-app 的版本绑定比较紧密。当 uni-app 官方发布新版本或 HBuilderX 推出新特性时框架可能需要跟进适配。如果框架维护者更新不及时你会陷入一个尴尬的处境项目代码不想动但又想用新特性框架不升级又可能跟最新的微信基础库或 App SDK 产生兼容问题。这是所有重型框架的共性风险unibest也没办法完全避免你在选型时必须把这个因素考虑进去。另外框架的思想需要通过长期使用才能消化。很多人在项目中用了unibest但当他们跳出这个框架去写别的项目时会发现自己对 uni-app 本身的理解并没有那么深——他们熟悉的是“unibest 里的 uni-app”而不是“原生 uni-app”。如果你希望团队成员真正吃透底层技术纯靠框架可能不是最优路径。4. 正面硬刚从初始化体验到长期维护的逐项对比为了让你看得更直观我把两个方案在几个关键维度上的表现整理成了一张表。这里的结论来自我自己的实测和多个项目的经验供你参考。对比维度meng-xi/create-uni-appunibest初始化速度1~3 分钟选完模板即可稍慢模板更复杂但仍在可接受范围上手门槛低熟悉 uni-app 即可中高需要理解框架约定技术栈自由度高完全自己决策低框架替你定了一套标准开箱即用程度低工程能力需自己补高请求/状态/规范/样式都已内置团队规范化依赖团队自律结构强制天然一致长期维护成本无框架升级负担但工程债可能逐渐累积框架升级需要跟进但工程标准化收益明显适合团队规模1~3 人小团队、个人项目3 人以上、需要统一规范的团队适合项目周期短期到中期页面型应用中期到长期业务逻辑复杂应用调试排查难度低链路透明偏高需理解框架封装逻辑迁移灵活性随时可做任何改造迁移成本大但项目内演进路径清晰光看表格也许还不够我再补三个具体的场景对比。场景一临时起意做一个小工具型小程序。比如一个内部用的打卡应用页面不超过10个不需要登录体系数据交互也简单。这种情况我用meng-xi/create-uni-app半个小时就能把项目搭起来、页面写完、真机预览。如果上unibest光是把框架结构跑通、理解它为什么要放这些目录就已经超过这个小工具的工作量了属于典型的杀鸡用牛刀。场景二公司级中后台业务 App 小程序双端。这种项目逻辑复杂、参与人多、迭代周期长而且对代码稳定性和可维护性要求极高。我自己在这种项目上更倾向于用unibest。因为团队人多的时候统一规范比个人自由重要得多而且框架提供的请求封装、状态管理方案可以减少很多低级bug。你要理解的是在这种项目里框架的约束不是阻碍你而是保护你。场景三技术储备性质的长期项目未来可能被多个业务线复用。这种情况我反而不建议直接上重型框架。因为你要做的其实是“沉淀自己的工程能力”而不是“复制别人的工程架构”。先用脚手架搭一个干净的基底然后把你认为重要的工程实践一点点放进去——这比直接引入一个别人的框架更能让你理解“为什么需要这些”。5. 选型判断别再问“哪个好”要问“你的项目属于哪一类”5.1 这些信号出现时选脚手架更合适我总结了一些我自己和身边朋友常用的判断信号。如果你的项目命中以下多条脚手架大概率是更好的起点项目规模清晰可预估页面数量可能就 10~20 个业务逻辑不复杂团队成员少或者都是资深开发者不需要框架来约束规范你对 uni-app 本身的掌握还不够深希望先专注学明白底层而不是再叠加一层概念项目是探索型的需求变化快很可能做着做着方向就变了不需要投入大量工程化基建你也享受“亲手搭建工程体系”的过程愿意花时间把项目打磨成更符合自己习惯的样子在这些情况下选脚手架你会感受到一种“松快感”没有任何多余的约定写的每一行业务代码都直接服务于业务本身。5.2 这些信号出现时重型框架是更稳的选择反过来以下信号表示你应该认真考虑unibest团队规模在 3 人以上而且会持续有新成员加入项目包含复杂业务逻辑涉及大量接口调用、权限控制、多角色状态管理你们吃过“代码风格不统一”“没有规范约束”的亏希望从源头解决项目生命周期长预期维护 2 年以上需要长期可维护性团队里缺乏专职架构师希望借助成熟框架的能力来保障工程质量特别是在“团队没有明确架构师角色”的情况下unibest这类框架的价值会格外突出。它相当于“一个隐形的架构师”把大部分关键决策都做好了你只需要专注业务开发。5.3 迁移成本先轻后重远比你想的贵有一个问题大家很容易忽略选型错误之后的迁移成本。如果你一开始用了脚手架后来项目复杂到需要框架级的约束想迁移到unibest会遇到什么你会面临以下工作把现有项目的目录结构调整到框架约定的结构把所有页面里直接调用的uni.request改成框架封装的请求方法引入 pinia 并重构现有的全局状态管理补上 eslint、prettier、husky 这些规范工具并处理旧代码里的大量 lint 报错适配框架内置的样式方案比如从 scss 切换到 UnoCSS带来的样式不一致这基本等同于把项目重写一遍。反过来如果一开始用了unibest后来想降级到脚手架反而简单一些——因为你至少可以保留已经写好的业务代码只是去掉框架层。所以如果你拿不准我个人的建议是宁可先用脚手架搭一个简单的再逐步加约束也不要轻易把一个重型框架引入到一个还不确定规模的项目里。轻的东西想加重可控重的东西想变轻等于推倒重来。6. 第三条路从脚手架起步逐步长出适合自己的轻框架6.1 如何吸收 unibest 的思想而不复制它的全部现在你可能在想我既想要脚手架的轻量自由又想要框架的规范统一有没有第三条路我的答案是有而且这其实是我目前最推荐的一种做法。以meng-xi/create-uni-app生成的干净项目为基底按需吸收unibest等重型框架的设计思想逐步演进出一套适合自己的“轻框架”。具体怎么做我建议按下列顺序渐进式引入第一步先把代码规范基础设施搭起来。这是投入产出比最高的一步。引入eslintprettierhuskylint-staged保证提交到仓库的代码风格一致。这一步的做法可以直接参考unibest的配置成本很低但能规避后续几乎所有“代码风格争论”。第二步封装一个统一的请求层。基于uni.request写一个简单的request.ts把 baseURL、token 注入、错误码拦截、统一提示做好。这是 uni-app 项目里最值得做的封装几乎每个业务项目都需要而且封装难度不高。完成后团队的接口调用方式就有了统一入口。第三步引入 pinia 并按模块组织 store。当项目开始出现跨页面共享状态时及时引入 pinia按业务模块拆分 store。这一步的关键是约定“什么数据适合放 store什么数据应该留在组件内部”这个度只能靠团队自己把握。第四步沉淀自己的通用组件和工具函数。把项目里重复出现的 UI 部件空状态、导航栏、列表项等抽成组件把通用逻辑日期格式化、防抖节流、文件上传等抽成utils。当这些积累到一定程度你的项目事实上就是一个“长在你业务场景上的框架”了。6.2 一个可落地的渐进式演进路径下面是我在团队里实际推进过的一套路径你可以参考第1周用create-uni-app初始化项目保证能编译到微信小程序和 H5第1周末加上 eslint/prettier/husky统一编辑器配置第2周完成request.ts封装改造所有页面里的网络请求第3周引入 pinia规划全局状态目录结构第1个月末整理出第一个公共组件库制定简单的组件规范第2~3个月根据团队反馈持续调整约定把“隐性知识”写进 README这样走下来你的项目到后期虽然不如unibest那么“全套”但它每一个约定都是团队自己认同并经过实践验证的。团队成员的认同感会比直接空降一个框架高很多。6.3 维护自己的“半框架”会遇到的坑不过第三条路也有它自己的坑我踩过之后总结给你约定容易“写少”。团队初期总觉得“这个不用写文档吧大家都知道”结果三个月后新来的同事一脸茫然。建议从第一天起就把约定写进项目 README宁可过度记录也不要依赖口口相传。封装容易“过度”。很多人封装 request 的时候喜欢把重试、取消、缓存、节流全都做进去。但封装越复杂出 bug 时排查越困难。你完全可以先支持基础功能等真实需求出现再加。公共组件容易“泛滥”。组件库最忌“见一个抽一个”很多组件只被用了两次就被抽出来反而增加了维护点。建议一个组件至少被三个业务页面复用才考虑收编进公共库。规范和自由要保持平衡。如果约定太死开发效率会下降如果太松规范形同虚设。我的经验是只强制约束那些“影响协作”的规则如目录结构、接口封装方式个人偏好类规则不要管太细。我自己走了这条路之后最大的感受是它比直接用unibest慢但这种慢是值得的因为团队在演进过程中真正理解了“为什么要这样设计”。等到你手里沉淀出一套贴合自己业务和团队习惯的“轻框架”之后你会获得比“直接用别人框架”更踏实的掌控感。回到最初的问题meng-xi/create-uni-app和unibest的定位之争本质上不是一个技术之争而是一个工程哲学的取舍。脚手架把自由和成长留给你重型框架把规范和效率带给你两者都有各自的适用场景。我个人的做法是小型项目、探索项目用脚手架大型项目、多人协作用框架而最有趣的项目从脚手架开始一点点长成只属于自己的那个“轻框架”。你可以从今天开始用一条命令创建一个最小项目然后亲手决定它下一步往哪里走。