模拟执行命令行界面设计细节 | AI生成和翻译

Home 2026.04

问题： CLI工具中的--dry-run是不良实践吗？我们很少使用它，Git已经提供了保护，而它会增加代码复杂度。那么，这个选项是否真的只适用于rm -rf这类破坏性命令？

回答：

你的直觉部分正确，但完整情况更为微妙。以下是一份结构化分析：

--dry-run通常并非不良实践

它其实被视为标准的CLI设计模式。clig.dev上的CLI指南将-n, --dry-run列为标准标志，其含义为“不执行命令，而是描述如果命令执行将会发生哪些变化”。

你关于其真实成本的观点是正确的

不足之处在于，--dry-run标志确实会对代码造成一定的“污染”。在各个主要阶段，你都需要检查该标志是否被设置，并且只打印将要执行的操作而不实际执行。

所以是的——它确实会增加实现复杂度。这是一个合理的工程权衡。

但它的作用与Git不同

Git保护的是源代码历史，而不是运行命令可能产生的副作用。--dry-run在下列情况下很有价值：

Git无法保护你免受这些操作的影响。曾有开发者构建了一个报告应用程序，它读取数据库、生成报告、进行压缩、上传到SFTP、检查错误响应并发送通知邮件——在整个开发和测试过程中，--dry-run标志被证明是无价之宝，每天都会被频繁使用多次。

你关于rm -rf的直觉是对的——但仅限于一类命令

CLI指南建议：对于“中度”危险的操作——例如删除目录、远程变更，或无法轻易撤销的复杂批量修改——通常你应该提示用户确认，并考虑为用户提供“预演”操作的方式。

因此，--dry-run在以下情况最为合理：

  1. 操作不可逆（无法通过Git或任何回滚机制撤销）
  2. 影响范围广（影响多个文件、记录或远程系统）
  3. 非交互式（在脚本、自动化流程或CI/CD中运行）

使用dry-run可能是过度设计的场景

具体到ww update的情况

ww update --dry-run会检查是否有可用更新而不实际拉取它们。这是一种对“将会”发生变化的只读预览。这是一个真正有用的模式——尤其是在自动化流水线中，你希望检测是否有可用更新并发出警报，而不是盲目应用它们。这并非出于对rm -rf的恐惧；而是关于可控的自动化。

总结

场景 Dry-run是否有价值？
破坏性操作（删除、覆盖） ✅ 是
远程副作用（上传、邮件、部署） ✅ 是
需要预览的自动化/CI流水线 ✅ 是
Git已涵盖的简单本地操作 ❌ 可能不必要
已内置y/n确认提示的命令 ❌ 可能不必要

--dry-run标志并非适用于所有场景，但当它适用时——特别是对于那些可能产生变更的命令驱动型工具——它可以非常有用。

参考文献：

Back Donate