后续路线

更新：2026-11-04。代码基线：bd5c662，package.json 版本：0.4.1。

方向：让小程序团队稳定接入、执行和排查发布流程。优先做可靠性、真实平台验证和交付体验，再按使用反馈扩展工作流。

本文是实施规划，版本号是建议的交付窗口，未勾选事项均未完成。本次代码盘点不代表 npm、Marketplace 或真实平台验收通过。旧路线中的 v0.4～v0.8 编号不再作为实施进度依据，历史内容可通过 Git 查询。

#1. 产品定位与范围

核心用户是使用 uni-app 或原生小程序的开发者，以及维护项目流水线的团队。主流程保持清晰：构建产物 → 本地检查 → 上传 / 预览 → 结果与产物交付 → 失败排查。

• CLI、JS API、GitHub Action、Vite 插件共享执行与结果语义。
• 微信作为优先验证链路；支付宝、钉钉按已接入能力维护，有真实项目后补齐对应验收。
• 接受任意构建工具生成的有效小程序产物；构建仍由项目现有脚本负责。
• release 当前代表构建和上传编排，不承诺平台审核、上架或线上回滚。
• 现有 IDE 联动继续维护；近期投入集中在 CI 主流程。

按个人或小团队维护规模规划，每次推进一个主要里程碑。没有用户反馈、性能数据或平台实测依据的扩展，不直接进入开发。

#2. 当前基线：已有能力与实际缺口

#已有实现

#影响下一阶段排序的发现

1. 运行时需要更新。 当前 engines 为 Node >=20，常规 CI 主要覆盖 20/22。官方当前将 20 标记为 EOL，22/24/26 为 LTS；应先验证 SDK 组合，再调整默认值和支持范围。Node.js 官方版本状态
2. 执行完成与业务结果需要分开。 上传成功后预算超限会使整体失败；网络超时也不能证明远端未收到上传。重试前需要知道已发生的副作用。
3. 版本来源需要透明。 src/version-strategy.ts 会吞掉查询异常并使用其它平台或本地版本；需要让用户看见来源、降级原因及冲突风险。
4. 已有测试基础应补缺口。 覆盖率阈值已设为 95%，但常规 CI 和发布校验调用普通测试命令，未实际执行覆盖率门禁。能力自检已经包含 pack / install，应扩展现有流程。
5. 接入后仍缺少方便消费的结果。 Action 已支持命令和 summary，但缺结果文件、二维码路径等 outputs；本地 history 在临时 Runner 中需要显式保存与恢复。
6. 真实支持范围需要证据。 本次未执行平台上传，也未核验线上发布状态；支持矩阵应记录 SDK、Node、系统、项目类型与验证记录，避免把 mock 成功写成平台可用。

#3. 分阶段路线

M0 → M1 → M2 顺序推进；真实平台验证贯穿每个阶段。M3 不是发布 1.0 的前置条件。

#M0：把当前版本的支持承诺做实

交付内容

• 建立能力与验证矩阵及验收记录模板：分别记录实现、离线测试与真实平台证据；尚无证据的组合标为待验证。
• Linux Node 24/26 安装、构建、测试与打包消费验证，以及 Windows / macOS Node 24 的矩阵，在提交 66a5fd5 的远端 CI 中通过；运行链接见运行时记录。候选默认值为 Node 24，真实平台 SDK 实测通过后再切换；后续提交需重新验证。
• 在单个 Linux Node 24 job 执行 pnpm test:coverage，保留现有 95% 阈值并上传报告；其它组合运行常规测试。提交 66a5fd5 的远端门禁及报告上传已通过，见运行时记录。
• 基于现有 upload-playground.yml 补真实上传 / 预览验收清单、预览入口与环境记录；平台实测按矩阵另行验收。
• 核对 npm 包、完整版本 tag、GitHub Release、Marketplace listing 和浮动 tag 的一致性，记录结果；沿用现有发布脚本。
• 更新支持政策：0.4.x 保留既有兼容范围；如提高 Node 最低版本，放入明确标注的 0.5 兼容性变更，附迁移说明。未验证的 Node / SDK 组合不列为正式支持。

验收条件

• 有一份可追溯的基线记录；失败或缺凭证的项标为待验证，不能标为通过。
• 正式宣称支持的运行时组合通过离线检查；微信主链路至少有一次真实上传与预览记录。支付宝、钉钉未完成的实测单独披露。
• 发布状态逐项记录，不能以“工作流文件存在”替代线上核验。

#M1：让执行可结束、失败可解释

交付内容

• 为 upload / preview / release 引入一致的超时和取消策略；CLI 提供超时配置，JS API 接收取消信号。区分构建超时、平台超时、用户取消。
• 明确 SDK 取消边界：不能只用 Promise.race 返回错误却继续后台上传；不支持取消的 SDK 评估子进程隔离，并验证进程树清理。远端提交结果无法确认时记录为 unknown。
• 统一结果语义：保留兼容的 ok，另行表达执行阶段、上传是否完成、预算判定、历史 / 评论警告与远端状态。已有公开字段不在补丁版本直接改名。
• 自动版本策略按实际上传目标查询，输出基础版本来源、逐平台查询状态和降级警告；strict: true 要求全部目标查询成功。依据进入 JS / JSON / summary / 发布历史；dry-run 保持离线且标记暂定。支持范围与并发限制见 版本策略，不保证全局唯一递增。
• 补 release 的分阶段检查：构建前检查配置与必要凭证，构建后检查产物；--skip-build 检查现有产物。dry-run 明确区分“计划生成”与“产物已验证”。
• 增加错误分类与处理建议，覆盖权限、白名单、版本冲突、产物缺失、超时等；未知错误保留可诊断原因，日志、JSON、summary、history 对凭证做一致脱敏。
• 只对可确认安全的只读查询引入有上限的重试。上传结果未知时默认不自动重试，也不自动删除版本或回滚其它平台。

验收条件

• 使用假 SDK / 子进程复现永久挂起、取消、部分平台失败，断言进程确实结束、后续任务按策略停止或继续、结果可序列化。
• 上传已完成但预算超限时，输出能明确表达两种状态；评论失败不会被误报为上传失败。
• 版本查询失败的来源和回退原因可见；dry-run 不触发构建、上传、评论或历史写入。
• CLI / JS API / Vite 共用行为；真实网络异常的人工验收与离线模拟分别记录。

#M2：让接入和交付成为可复用流程

交付内容

• Action 增加稳定 outputs，优先提供结果 JSON 文件、summary 文件、二维码产物路径和实际 CLI 版本；多平台结果放入 JSON，避免为每个平台扩充输入输出。
• 补预览产物 artifact 示例、失败结果保留和 PR 反馈模板；先复用现有 release 评论能力。二维码 artifact 的下载入口不承诺可以直接作为评论中的图片地址。
• 补 history 保存 / 恢复示例，按应用和环境隔离历史及体积趋势；发布记录带版本、commit 和产物标识。明确本地原子写入不提供跨 Runner 并发保护。
• Action 输出实际执行的包版本及解析来源；审查浮动 ref 回退 latest 的行为，提供明确的版本锁定方式，避免用户无法复现。
• 将 README 保留为快速开始和核心参考，把较长的 CI、诊断、平台限制指南拆到 docs/；每个示例标注已验证的入口。
• 提供 GitHub Actions、GitLab CI、Jenkins / npm scripts 的最小示例：构建 → doctor → upload / preview → 收集结果。复用 CLI，不为每个 CI 平台再建一套执行逻辑。
• 改善 init 的探测说明、必填项提示和非交互体验；保留现有配置，不默认修改用户流水线。

GitHub composite action 可通过步骤的 GITHUB_OUTPUT 映射公开 outputs；本阶段采用官方机制。GitHub composite action 文档

验收条件

• 至少两个仓库外的消费者项目完成接入，其中一个通过 GitHub Action，一个通过 CLI / JS API；至少一个项目走通真实上传和预览。
• 单平台和多平台成功 / 失败都有机器可读结果；后续步骤无需解析人类日志。
• 新 Runner 恢复正确历史后能展示体积差异，换应用或环境不会混用历史。
• fork PR 无凭证时执行明确的离线路径，不尝试真实上传。

#M3：在反馈明确后扩展工作流

以下项目独立排序，不打包成一个大版本。每项开始前需要两个具体使用场景，或一个已有项目中可复现、反复出现的阻塞。

#4. 架构调整跟随交付

• 先收敛执行与结果。 把批量上传和 release 的公共执行逻辑集中，避免超时、预算与错误处理分别实现。
• 能力声明保持内部使用。 平台 / 项目类型的能力判断集中为数据，供 doctor、plan 和命令复用；有第三方适配需求前不发布通用插件协议。
• 逐步拆分命令处理。 src/cli.ts 当前约 830 行，随 M1/M2 按命令提取处理器；保留 runCli / parseCliArgs 的公开兼容性，不先做大规模目录重构。
• 逐步统一输出。 现有 JSON、Markdown 输出消费公共结果；为命令成功、参数错误、执行失败建立契约样例，明确 schemaVersion 升级规则。
• 持续保留打包消费者验证。 同时覆盖 ESM 与 CommonJS 项目的配置加载、CLI 和库导出，不重复建设已有 pack / install 流程。

#5. 暂缓事项

#6. 1.0 的门槛

1. 正式支持的 Node / 系统 / SDK 组合有维护矩阵；每个正式支持的平台都有真实上传证据，预览等额外能力按矩阵验收。
2. 至少两个外部消费者项目连续使用两个迭代周期，核心链路无未解决的阻塞问题；周期建议按两周复盘。
3. 配置、CLI 参数、JS API、JSON 与退出码有明确兼容规则，旧配置迁移路径可执行。
4. 超时、取消、部分失败、上传后预算超限、版本回退均可解释；涉及凭证的输出完成脱敏验证。
5. npm / Action 版本对应、打包消费验证、发布记录与升级说明完整。

按验收门槛发布 1.0，不要求 watch、monorepo、更多平台或插件市场全部完成。

#7. 下一轮可直接执行的任务

建议按以下顺序拆为小 PR；这是规划清单，不代表已经创建 Issue 或开始实现。

先完成任务 1～2 校准基线，再推进任务 3～5，验收后发布 0.5；任务 6 作为 0.6 的起点。排期以 SDK 兼容验证和真实平台可用条件为依据，不在缺少这些条件时承诺发布日期。

每个里程碑结束记录：首次接入遇到的步骤、失败原因分类、安装与执行耗时、已验证组合及未解决问题。根据这些记录调整下一阶段，不以新增命令数量衡量进展。