3、核心命令解析（下）：rmc test、rmc deploy、rmc clean 的实战技巧
好，咱们接着聊。上一节我们把 rmc build 和 rmc run 掰开揉碎讲了一遍。今天要聊的三个命令，说实话，才是真正决定你开发效率的关键。
我个人习惯把 rmc test、rmc deploy、rmc clean 称为「三驾马车」。一个负责质量，一个负责交付，一个负责打扫战场。缺一个，你的工作流就会卡住。
3.1 rmc test：不只是跑个绿勾
很多人觉得测试就是跑一下，看到绿色就完事了。嗯，我以前也这么想。直到有一次，我在项目里改了一个看似无关紧要的配置，结果把整个模块的依赖链搞断了。测试全绿，但部署上去就崩。
为什么会这样？因为默认的 rmc test 只跑单元测试，它不检查集成和端到端。
核心用法：
# 基础测试
rmc test
# 带覆盖率报告
rmc test --coverage
# 只跑某个模块
rmc test --module=payment
# 跳过某些测试
rmc test --skip=slow-tests我在项目中遇到过最坑的一次，是某个同事提交代码前只跑了 rmc test，没加 --coverage。结果覆盖率从 85% 掉到了 40%，没人发现。等合并到主分支后，CI 直接挂了。
我的建议：每次提交前，至少跑一次带覆盖率的测试。养成习惯，不然后面补测试比写代码还痛苦。
还有一个实用技巧：rmc test --watch。这个模式会监听文件变化，自动重新跑相关的测试。说白了，就是边写代码边看结果，不用手动敲命令。我写 TDD 的时候必开这个。
3.2 rmc deploy：一键上线的艺术
部署这件事，说白了就是把你的成果送到该去的地方。但「该去的地方」往往不止一个。
我记得刚接手一个老项目时，部署脚本写了三百多行，每次上线都要手动改十几个参数。后来我用 rmc deploy 重构了整个流程，把部署时间从 40 分钟压缩到了 3 分钟。
常用场景：
# 部署到开发环境
rmc deploy --env=dev
# 部署到生产环境（带确认）
rmc deploy --env=prod --confirm
# 指定版本号
rmc deploy --env=staging --version=2.1.0
# 回滚到上一个版本
rmc deploy --rollback这里有个坑，我曾经踩过：rmc deploy 默认会执行构建流程。如果你本地有未提交的修改，它会直接报错。这个设计其实很合理——你想想看，部署一个「脏」代码上去，出了问题谁负责？
避坑指南：我曾经在周五下午五点执行 rmc deploy --env=prod，结果忘了加 --confirm 参数。命令直接执行了，连个确认提示都没有。后来我养成了一个习惯：生产环境部署，永远手动加上 --confirm，给自己留一个思考的缓冲。
还有一个冷门但好用的参数：--dry-run。它会模拟整个部署流程，但不会真的执行。我每次改部署配置后，都会先跑一遍 dry-run，确认没问题再真上。
3.3 rmc clean：打扫干净再出发
这个命令看起来最简单，但用好了能省你不少硬盘空间和编译时间。
默认情况下，rmc clean 会删除构建产物和缓存文件。但你知道吗？它其实可以更精细地控制。
清理选项：
# 基础清理
rmc clean
# 只清理缓存
rmc clean --cache
# 只清理构建产物
rmc clean --build
# 清理所有（包括日志、临时文件）
rmc clean --all我个人习惯在每次大版本迭代前，跑一次 rmc clean --all。为什么？因为项目跑久了，各种临时文件、日志、缓存会堆积。有时候你遇到一些莫名其妙的 bug，其实就是缓存搞的鬼。
一个小技巧：如果你发现 rmc build 突然变慢了，先别急着优化代码。试试 rmc clean --cache，有时候能立竿见影。我在一个老项目上试过，清理后构建时间从 120 秒降到了 45 秒。
嗯，这里要注意一点：rmc clean 不会删除你的源代码，但它会删除 node_modules 吗？默认不会。但如果你加了 --all 参数，它会询问你是否要删除依赖目录。我建议除非你确定要重新安装依赖，否则别选 yes。
3.4 三个命令的协作流程
说了这么多，这三个命令到底怎么配合？我画了一张图，你看完就明白了。
你看，整个流程其实是个闭环。开发完跑测试，测试通过就部署，部署完清理环境。如果部署失败，回滚后重新来。说白了，就是一套标准化的「开发-验证-交付-清理」流水线。
最后分享一个我自己的习惯：每次下班前，我都会在终端敲一句 rmc clean --cache。第二天早上来，环境干干净净，心情也好。你试试看？