构建、预览与上传
很多项目在“能开发”之后，第一次真正上线时才发现流程并不完整。
例如：
- 本地 dev 正常，但 build 产物不完整
- 开发者工具导入的不是正确目录
- 真机和开发者工具表现不一致
所以发布流程最好不要临时拼，而要尽早固化。
一条最小可执行的发布流程
你可以先把项目流程固定成下面这样：
txt
1. 本地构建
2. 开发者工具打开 dist
3. 关键页面回归
4. 真机预览
5. 上传版本第 1 步：先构建
bash
pnpm build构建完成后，不要只看“命令通过了没有”，还要看：
dist是否完整- 关键页面是否都生成了
- 分包目录是否符合预期
第 2 步：确认开发者工具看的目录对
这是一个非常高频的坑。
你要确认开发者工具导入的是最终产物目录，而不是源码目录。 也就是说，miniprogramRoot 应该和当前项目输出目录对齐。
第 3 步：做一轮关键路径回归
新用户最容易跳过这一步，但它实际上非常重要。
至少建议手动走一遍：
- 首页打开
- 登录流程
- 列表页进入详情页
- 表单提交
- 关键分享或支付前流程
你不需要把所有边角场景都点一遍，但核心业务链路一定要确认。
第 4 步：真机预览
开发者工具通过，不代表真机一定通过。
真机更值得关注：
- 登录授权
- 图片和静态资源
- 网络请求域名
- 页面切换与分享
- 长列表和滚动体验
第 5 步：上传
如果你的团队已经接入命令行工具链，可以进一步把流程标准化。
例如，项目里经常会把这些动作写进脚本：
bash
pnpm build
pnpm open
pnpm preview
pnpm upload关键不是命令长什么样，而是团队知道：
- 谁负责构建
- 谁负责验证
- 哪个版本对应哪次上传
一个很实用的发布前检查清单
txt
[ ] 当前分支代码已确认
[ ] pnpm build 通过
[ ] dist 关键页面产物完整
[ ] 开发者工具导入目录正确
[ ] 关键业务路径已回归
[ ] 真机至少验证一轮
[ ] 上传版本号和说明明确什么时候适合接入命令行 IDE 流程
如果你的项目已经进入稳定迭代，可以考虑把：
- 打开 IDE
- 预览
- 上传
这些步骤逐步脚本化，这样更适合团队协作和 CI/CD。
一个给新用户的建议
先把“本地 build -> 开发者工具导入 -> 真机验证”这条最短链路跑通。 不要一开始就把所有发布自动化做得很重。
看完这一章后，你可以继续看：