TG咨询移动端验收不必在每次提交后都全量运行。配置“应用研发持续集成中移动端验收任务触发条件”时，可先判断改了什么，再确认基础构建是否成功，最后决定是否进入设备或模拟器验收。这样既能减少无关任务，也能避免构建失败后继续消耗验收资源。
先把触发判断拆成三道门
一套容易维护的规则，通常由代码范围、提交场景和构建状态组成。代码范围决定任务是否相关；提交场景区分拉取请求、主干合并或手动发布；构建状态则保证验收针对的是可安装、可运行的产物。
| 判断项 | 适合触发验收的情况 | 可以跳过的情况 |
|---|---|---|
| 文件变更 | 应用源代码、界面资源、路由或关键配置有变化 | 只修改与移动端无关的文档，且文档不参与构建 |
| 提交场景 | 拉取请求准备合并、主干提交或候选版本验证 | 个人分支上的无关改动，且团队不要求每次提交验收 |
| 构建状态 | 对应平台的编译与基础测试通过，验收产物已生成 | 编译失败、测试失败或产物缺失 |
这些条件应明确为“全部满足”还是“满足其一”。例如，拉取请求中只要移动端代码有变化，就先构建；构建成功后再启动验收。不要把“代码变化”和“构建成功”当作可互相替代的条件。
按变更范围选择验收粒度
局部改动先跑针对性检查
如果改动集中在某个页面或模块，可先运行相关单元测试及少量 smoke test（冒烟测试），确认基础路径可用。移动端项目还要留意共享代码：修改网络层、登录状态或导航组件，可能影响多个页面，不宜只按文件所在目录缩小范围。
公共配置变更扩大覆盖面
依赖版本、构建配置、资源处理、权限声明或平台适配代码变动时，宜运行对应平台的完整构建，并扩大验收设备或模拟器覆盖。Android 项目可将 Gradle 构建与测试结果作为后续任务的前置条件；iOS 项目可检查 Xcode 构建及测试任务是否成功。两类任务应分别判断，Android 成功不代表 iOS 也已通过。
在 GitHub Actions 等 CI（持续集成）平台中，可以依据拉取请求事件、分支条件和变更路径筛选任务，再用任务依赖关系要求验收等待构建完成。GitLab CI 也支持按变更文件配置规则。无论使用哪种平台，都要确认路径匹配包含新增、删除和重命名文件，避免规则只覆盖普通修改。
可执行的配置步骤
- 列出文件类别：区分应用代码、测试代码、构建配置、共享资源和纯文档，并标明哪些变化会影响安装包。
- 确定触发场景：分别定义拉取请求、主干合并、候选版本和手动重跑的规则；发布相关验收通常应比普通提交更完整。
- 设置构建门槛：将对应平台的构建及必要基础测试设为验收前置任务。失败时停止后续验收，并保留失败日志供排查。
- 传递同一份产物：让验收使用该次构建生成的构建产物，不要在验收阶段悄悄重新构建另一份，否则结果可能无法对应提交。
- 用边界改动验证：分别提交一次纯文档改动、一次移动端页面改动和一次公共配置改动，检查任务是否按预期跳过、启动或扩大范围。
- 定期复核规则：新模块、目录迁移或平台增加后更新路径条件，并查看被跳过任务的原因，防止规则长期失效。
避免三个常见配置误区
第一，不能只看文件路径。共享库或生成配置可能影响应用，却不在直观的页面目录中。第二，不能只看构建任务“已结束”；必须区分成功、失败和取消。第三，不能让验收只在主干运行。若团队需要在合并前发现问题，拉取请求阶段也应有对应检查，只是可以采用较轻的覆盖范围。
因此，应用研发持续集成中移动端验收任务触发条件，核心不是把任务尽量开得频繁，而是让变更范围、提交阶段与构建结果共同决定验收级别，并确保结果对应清楚的代码版本。
常见问题
只改文档时是否应运行移动端验收？
若文档不参与应用构建，也不影响生成内容，通常可以跳过；若文档会生成应用内帮助页或资源，则应按实际构建依赖判断。
构建成功但基础测试失败，还要启动设备验收吗？
通常不应直接启动完整验收。先处理失败；只有团队明确把该测试设为非阻断项时，才按既定规则继续，并记录例外原因。
Android 和 iOS 能共用一个触发条件吗？
可共用代码变更和提交场景的判断，但平台构建状态应分别检查；平台专属文件变更还应触发对应平台任务。
怎样确认路径过滤没有漏掉重要改动？
用代表性的新增、删除、重命名和共享配置改动做边界验证，并检查 CI 记录中的触发或跳过原因。目录结构调整后重新复核规则。