不建议从零手写脚手架，但必须基于官方@ dcloudio/uni-preset-vue定制并私有化托管；需补全请求拦截、Pinia持久化、组件自动导入等团队约束，并通过fork、修改、私有npm发布实现统一工程规范。
团队内部搭建 uni-app 脚手架，核心不是“能不能搭”，而是“要不要自己维护一套模板”。答案很直接：不建议从零手写脚手架，但必须基于官方 preset 定制并私有化托管。uni-app 官方的 @dcloudio/uni-preset-vue 已覆盖 Vue 3 + Vite + TypeScript + Pinia 等主流组合，强行另起炉灶只会增加 CI/CD、依赖升级、多端兼容的维护成本。
为什么不能直接用 vue create -p dcloudio/uni-preset-vue 就完事？
因为默认 preset 缺少团队级工程约束：
- 没有预置统一的请求拦截封装（比如自动携带 token、错误码全局 toast）
- 没有标准化的 Pinia store 目录结构和持久化策略（
pinia-plugin-persistedstate配置位置、storage key 命名规则） - 缺少团队约定的组件自动导入规则（
unplugin-vue-components的dirs路径、exclude规则） - 没有预设 H5 端路由 base、小程序分包配置、App 端原生插件声明等平台特异性字段
-
manifest.json和vue.config.js（或vite.config.ts）里硬编码了示例值，无法开箱即用
怎么把官方 preset 私有化为团队脚手架？
关键动作是 fork + publish + 替换模板源，而不是重写逻辑：
- 去 GitHub 克隆
dcloudio/uni-app仓库，定位到packages/uni-preset-vue目录 - 在 fork 后的分支中修改：补全
src/utils/request.ts模板、调整src/stores/index.ts初始化逻辑、更新vite.config.ts中的 alias 和 plugin 配置 - 用
pnpm pack打包，将生成的.tgz文件上传至团队私有 npm 仓库（如 Verdaccio 或 Nexus） - 团队成员执行
vue create -p @your-team/uni-preset-vue@1.0.0 my-app即可拉取定制版 - 后续所有 preset 更新都走同一套 CI 流程：PR → 自动测试 → pnpm pack → 发布新版本
uni-app 脚手架在 CI/CD 中容易崩在哪几个点？
这些不是开发时的问题，而是部署时高频报错位：
-
npm run build:mp-weixin在 Linux CI 环境失败：因为默认依赖 HBuilderX 的编译器，必须显式安装@dcloudio/uni-cli并配置UNI_CLI_MODE=auto - 微信小程序构建后
dist/dev/mp-weixin目录为空：检查vite.config.ts是否误删了uni: { platform: 'mp-weixin' }插件配置 - App 端打包提示 “找不到
nativePlugins”：manifest.json中的"nvueStyleCompiler"字段必须为"uni-app"，且nativePlugins数组需在根节点下，不能嵌套在h5或mp分支里 - H5 端路由刷新 404：Vite 默认不处理 history 模式回退，需在
vite.config.ts中配置server.historyApiFallback = true，同时确保 Nginx 配置了try_files $uri $uri/ /index.html;
真正难的从来不是“第一次跑起来”，而是“第 100 次发版时，新同学改了 vue.config.js 却没同步更新 CI 脚本里的 --mode 参数”。脚手架的价值不在功能多，而在所有人的 package.json 里 dev 命令行为一致、dist 目录结构可预测、git commit 前能自动校验 manifest 格式——这些细节，比选 Vite 还是 Webpack 更决定项目寿命。
