大佬们，求一个开发 命令行 工具的课程？

命令行程序一般分为两种类型，

• 只带选项和参数的
• 允许子命令的

先说只带选项和参数的，大概是分为 switch 和 option 两种。

• switch 表示一个开关，有就是 true，没有就是 false，比如 --force
• option 一般是一个键值对，就是给一个 key 再带一个相对自由的值，比如 --file a.txt

键值对根据不同的定义，又分好多种形式，不过常用的也就三种：

• --key value
• --key=value
• --key:value

其中后两种多用于 Windows 下，= 和 : 用来代替空格。

说到这里又得提到参数的表示形式，也跟系统有点关系，Linux 下多种 -c 和 --word 的形式，前者是简写，后者是全称（用单词全称比较容易理解）。

Windows 下从 DOS 继承的是 /xx，不分简称全称，使用 / 作为参数识别符，后来逐渐开始兼容 - 和 --。有些时候这两个符号都是代替 / 的，也有时候按 Linux 的规范来，最神奇的是有些命令行程序也会把 - 和 -- 识别为不同的参数，比如 -c 和 --c 不同……当然这种奇葩不推荐。

扯远了。现在既然是用库来定义和解析参数，那基本上都是 Linux 那种规范来的。解析器解析了这些参数之后，一般会把它们封装成一个 Option 对象（也就是说的 Option 模式），比如

{
    loadFromFile: true,
    file: "a.txt",
    verbose: false
}

接下来就是根据这个参数对象来实现你自己的命令行业务行为。具体业务具体分析，也没什么特别好说的。

如果是带子命令形式，比如 npm run serve，这里 run 其实是一个子命令。常见的还有 git 和 dotnet 这些都是以子命令形式实现的，dotnet 甚至还通过插件/组件来实现子命令的扩展。由于存在子命令，所以会行解析命令行的第一个参数来判断是什么命令，然后再解析后面的参数送给这个命令去处理它自己的业务。这种根据不同命令来进行处理，但又基本上是一致的调用逻辑（解析参数传给命令处理），可以参考 23 种设计模式中的命令模式 (Command Pattern)，或者用策略模式也可解决这类问题。

总之，组件就是帮你处理命令行参数的，但拿到参数之后怎么做，还是看你自己想实现的业务来