你还在用sys.argv硬编码吗是时候用Python认真做一款命令行工具了开发命令行工具CLI是Python开发者最常用的技能之一——从简单的自动化脚本到复杂的运维工具CLI无处不在。但很多人写了几年代码依然在用sys.argv解析参数、手动处理异常、把逻辑塞进冗长的if/elif分支里。这种代码不仅脆弱而且几乎没有复用性。今天我们将从零开始带你完整走一遍构建专业级CLI工具的路径并给出可直接运行的代码示例。为什么选择Python做CLI三个你无法拒绝的理由Python在CLI领域的统治地位并非偶然。第一生态系统极其成熟标准库里的argparse能处理复杂参数解析第三方库click和typer则让开发体验提升到“愉悦”级别。第二跨平台性无痛在Windows、macOS、Linux上可以写出几乎一模一样的代码打包成可执行文件后用户根本不需要装Python。第三与系统胶水能力Python能轻松调用Shell命令、操作文件、处理JSON/YAML这些正是CLI工具的日常。但很多人忽略了最关键的一点一个优秀的CLI工具应该像Unix哲学那样——做一件事、做好一件事并且可以组合。这意味着你的代码必须结构清晰、错误处理优雅、帮助文档完善。接下来我们按步骤开始。第一步奠定基础——用argparse实现最传统但扎实的方案假设我们要开发一个处理CSV文件的工具能够统计行数、列数、并支持输出不同格式。先看最经典的实现方式。# csv_stats.py import argparse import csv import sys def parse_args(): parser argparse.ArgumentParser(description统计CSV文件基本信息) parser.add_argument(input_file, help输入的CSV文件路径) parser.add_argument(-o, --output, help输出结果到文件不指定则输出到终端) parser.add_argument(-d, --delimiter, default,, helpCSV分隔符默认逗号) parser.add_argument(--no-header, actionstore_false, desthas_header, helpCSV文件没有表头) return parser.parse_args() def process_csv(file_path, delimiter, has_header): with open(file_path, r, encodingutf-8) as f: reader csv.reader(f, delimiterdelimiter) rows list(reader) if not rows: return None, 文件为空 header rows[0] if has_header else None data_rows rows[1:] if has_header else rows stats { 总行数: len(rows), 数据行数: len(data_rows), 列数: len(rows[0]), 表头: header, } return stats, None def main(): args parse_args() stats, err process_csv(args.input_file, args.delimiter, args.has_header) if err: print(f错误: {err}, filesys.stderr) sys.exit(1) if args.output: with open(args.output, w) as f: for k, v in stats.items(): f.write(f{k}: {v}\n) else: for k, v in stats.items(): print(f{k}: {v}) if __name__ __main__: main()这段代码虽简单但已经体现了CLI工具的三大核心原则清晰的参数界面、分离的逻辑函数、以及健壮的错误处理。argparse自动生成-h帮助文档actionstore_false巧妙处理布尔标志。很多初学者会犯的错误是把所有逻辑写在main()里导致无法单元测试。记住“main函数只负责分发”。第二步进阶——用click装饰器写出更优雅的代码argparse的缺点也很明显参数定义与函数分离代码量偏大。click通过装饰器将参数直接绑定到函数让代码的意图变得无比清晰。看同样的功能用click怎么写# csv_stats_click.py import click import csv click.command() click.argument(input_file, typeclick.Path(existsTrue)) click.option(-o, --output, typeclick.Path(), help输出文件) click.option(-d, --delimiter, default,, show_defaultTrue, helpCSV分隔符) click.option(--no-header, is_flagTrue, helpCSV没有表头) def main(input_file, output, delimiter, no_header): 统计CSV文件基本信息行数、列数、表头等 with open(input_file, r, encodingutf-8) as f: reader csv.reader(f, delimiterdelimiter) rows list(reader) if not rows: click.echo(文件为空, errTrue) return header rows[0] if not no_header else None data_rows rows[1:] if not no_header else rows stats { 总行数: len(rows), 数据行数: len(data_rows), 列数: len(rows[0]), 表头: header, } if output: with open(output, w) as f: for k, v in stats.items(): f.write(f{k}: {v}\n) else: for k, v in stats.items(): click.echo(f{k}: {v}) if __name__ __main__: main()对比argparse版本click的代码量减少了约40%而且参数类型会自动校验click.Path(existsTrue)会在参数无效时报错。click最强大的地方在于它对“子命令”的原生支持——想象一个工具叫data-tool下面有csv、json、yaml等子命令用click.group可以轻松实现。不过click也有其代价装饰器过多时调试比较困难而且对类型提示不够友好。这时就该typer登场了。第三步现代派——用typer写出带类型提示的CLI工具typer建立在click之上但大量利用了Python的类型注解来减少样板代码。上面的例子用typer写几乎是“秒杀”风格# csv_stats_typer.py import csv from typing import Optional import typer app typer.Typer() app.command() def stats( input_file: str typer.Argument(..., help输入的CSV文件路径), output: Optional[str] typer.Option(None, help输出文件), delimiter: str typer.Option(,, helpCSV分隔符), no_header: bool typer.Option(False, --no-header, helpCSV没有表头), ): 统计CSV文件基本信息 with open(input_file, r, encodingutf-8) as f: reader csv.reader(f, delimiterdelimiter) rows list(reader) if not rows: typer.echo(文件为空, errTrue) raise typer.Exit(code1) header rows[0] if not no_header else None data_rows rows[1:] if not no_header else rows typer.echo(f总行数: {len(rows)}) typer.echo(f数据行数: {len(data_rows)}) typer.echo(f列数: {len(rows[0])}) typer.echo(f表头: {header}) if output: with open(output, w) as f: f.write(f总行数: {len(rows)}\n) f.write(f数据行数: {len(data_rows)}\n) f.write(f列数: {len(rows[0])}\n) f.write(f表头: {header}\n) if __name__ __main__: app()typer通过函数签名自动推断参数是必须的还是可选的typer.Argument(...)表示必选位置参数typer.Option(None)表示可选选项。最令人惊艳的是错误输出——当参数类型不对时typer会打印出带颜色和位置提示的错误消息这比click的死板报错更友好。第四步构建可安装的包——让用户用pip install就能装你的CLI仅仅有一个.py文件是不够的真正专业的CLI工具应该可以像pip install my-tool一样安装然后系统里多出一个全局可用的命令。你需要一个setup.py或pyproject.toml。以下是现代推荐的方式pyproject.tomlsetuptools# pyproject.toml [build-system] requires [setuptools61.0, wheel] build-backend setuptools.build_meta [project] name csv-tool version 0.1.0 description 一个用于CSV文件统计的命令行工具 requires-python 3.8 dependencies [ click8.0, ] [project.scripts] csv-tool csv_tool.main:cli # 注意这里指向你的入口函数 [tool.setuptools.packages.find] include [csv_tool]假设你的代码放在csv_tool/目录下csv_tool/__init__.py可以为空csv_tool/main.py中包含你的cli函数用click.group或app。然后运行pip install -e .就可以在终端直接调用csv-tool命令了。最重要的是入口点[project.scripts]决定了用户调用的命令名和对应的函数。如果你用typer入口函数应该是一个typer.Typer()实例比如app()。第五步健壮性不是可选项——错误处理与日志CLI工具最讨厌的行为就是“静默失败”或“打印一堆traceback”。所有面向用户的输出都应该是人性化的。我有几条铁律所有异常都必须被捕获并给出清晰解释。比如文件不存在直接提示用户检查路径而不是FileNotFoundError。使用sys.exit(1)或raise typer.Exit(code1)表明非零退出码。管道命令依赖退出码判断成功与否。标准输出和标准错误严格分离正常结果打印到stdout错误和诊断信息打印到stderr。这样用户可以把正常结果重定向到文件而错误依然在终端显示。例如上面例子中click.echo(文件为空, errTrue)就是打印到stderr。如果你用argparse可以print(错误信息, filesys.stderr)。另外日志模块logging在CLI中非常有用。一般设计是默认只输出WARNING及以上级别用户可以通过-v或--verbose设置DEBUG。我通常这样封装import logging def setup_logging(verbose: int): level logging.DEBUG if verbose 0 else logging.WARNING logging.basicConfig(format%(levelname)s: %(message)s, levellevel)然后在主函数中根据verbose参数调用。第六步让CLI支持管道和重定向——遵循Unix哲学好的CLI工具应该能够与其他命令优雅组合。这意味着你的工具必须能接受标准输入当文件参数省略时并且输出格式要可以被后续命令解析。比如我们可以让csv-tool stats支持从管道读入数据click.command() click.argument(input_file, typeclick.Path(existsTrue), requiredFalse) def stats(input_file): 从文件或stdin读取CSV并统计 if input_file: f open(input_file, r, encodingutf-8) else: f sys.stdin # 直接用标准输入 # ... 处理逻辑 ...这是一个巨大的设计决策因为一旦支持stdin你的工具就变成了“过滤式”命令可以放在管道中间。比如cat data.csv | csv-tool stats。如果你还支持--json输出则可以用jq进一步处理。第七步测试你的CLI——从手动敲命令到自动化验证测试CLI工具有几种常用方法。最简单的是使用subprocess在测试中实际运行你的脚本并检查输出。但更高效的做法是利用click.testing.CliRunner也支持typer——它不需要真的启动新进程而是在内存中模拟调用。# test_csv_tool.py from click.testing import CliRunner from csv_tool.main import cli def test_stats_basic(): runner CliRunner() # 创建一个临时CSV文件 with runner.isolated_filesystem(): with open(test.csv, w) as f: f.write(a,b,c\n1,2,3\n4,5,6\n) result runner.invoke(cli, [stats, test.csv]) assert result.exit_code 0 assert 总行数: 2 in result.output assert 列数: 3 in result.outputrunner.isolated_filesystem()会创建一个临时目录测试结束后自动删除非常干净。你也可以测试错误场景比如不存在的文件应该返回非零退出码。第八步构建“智能”帮助信息——让用户不需要阅读文档一个真正优秀的CLI工具其帮助文档本身就是最好的用户手册。不要满足于自动生成的-h输出而是要精心设计描述文本。click和typer都支持在装饰器中添加help参数甚至支持导览示例epilog。例如click.command(epilog使用示例:\n csv-tool stats data.csv --no-header\n csv-tool stats data.csv -o result.txt) def stats(): ...我见过很多CLI工具参数名用单字母缩写但从不解释用户不得不猜。每一行帮助都应该回答“这个参数的作用”和“默认值是什么”。click的show_defaultTrue是个好习惯。第九步打包成单一可执行文件——无Python环境也能用当你写完CLI工具想让没有安装Python的同事也能使用可以选择打包成独立的可执行文件。常用工具有PyInstaller和Nuitka。以PyInstaller为例在项目根目录运行pip install pyinstaller pyinstaller --onefile --name csv-tool csv_tool/main.py生成的单一可执行文件在dist/csv-toolWindows下是csv-tool.exe大小约几MB。注意--onefile会打包Python解释器和依赖启动速度稍慢但分发方便。如果你想支持不同操作系统需要在对应的系统上分别打包交叉编译困难。第十步高级技巧——交互式CLI与进度条当你的CLI工具处理耗时较长的任务时静态输出远远不够。用户需要知道进度。我们可以用click.progressbar或第三方库rich的Progress来实现。比如读取大文件时显示行数import click with click.progressbar(lengthtotal_lines, label处理中) as bar: for line in file: # 处理一行 bar.update(1)更现代的方案是用rich库它不仅能显示进度条还能输出带颜色和表格的漂亮终端界面。例如from rich.progress import Progress, BarColumn, TextColumn import time with Progress(TextColumn([progress.description]{task.description}), BarColumn(), TextColumn({task.percentage:3.0f}%)) as progress: task progress.add_task([green]下载中..., total100) for i in range(100): progress.update(task, advance1) time.sleep(0.1)这样的交互体验会让你的CLI工具在同类中脱颖而出。记住用户的耐心是有限的进度条是对用户时间的尊重。总结从脚本到工具只差这十步我们走完了从零开始构建Python CLI工具的完整路径先选一个库argparse/click/typer然后设计参数、分离逻辑、添加错误处理、支持管道、编写测试、打包分发。最后的成品不再是“一个.py文件”而是一个可安装、可测试、可协作的软件工程产物。现在如果你还在用sys.argv写CLI不妨今天就开始重构。把每次的手动操作变成可复用的命令把散落在各个脚本里的逻辑收集成体系化的工具。当你的同事说“能不能帮我跑个数据”你只需要回答“你装一下这个包运行my-tool process就行”时你就真正掌握了Python CLI开发的精髓。下一步可以探索如何让你的CLI支持插件化动态加载子命令、如何实现自动补全shell completion、以及如何用asyncio做异步CLI。但这些已经是进阶话题了。先动手做一个你自己的工具吧——从今天开始。
用Python开发命令行工具：步骤与代码示例
你还在用sys.argv硬编码吗是时候用Python认真做一款命令行工具了开发命令行工具CLI是Python开发者最常用的技能之一——从简单的自动化脚本到复杂的运维工具CLI无处不在。但很多人写了几年代码依然在用sys.argv解析参数、手动处理异常、把逻辑塞进冗长的if/elif分支里。这种代码不仅脆弱而且几乎没有复用性。今天我们将从零开始带你完整走一遍构建专业级CLI工具的路径并给出可直接运行的代码示例。为什么选择Python做CLI三个你无法拒绝的理由Python在CLI领域的统治地位并非偶然。第一生态系统极其成熟标准库里的argparse能处理复杂参数解析第三方库click和typer则让开发体验提升到“愉悦”级别。第二跨平台性无痛在Windows、macOS、Linux上可以写出几乎一模一样的代码打包成可执行文件后用户根本不需要装Python。第三与系统胶水能力Python能轻松调用Shell命令、操作文件、处理JSON/YAML这些正是CLI工具的日常。但很多人忽略了最关键的一点一个优秀的CLI工具应该像Unix哲学那样——做一件事、做好一件事并且可以组合。这意味着你的代码必须结构清晰、错误处理优雅、帮助文档完善。接下来我们按步骤开始。第一步奠定基础——用argparse实现最传统但扎实的方案假设我们要开发一个处理CSV文件的工具能够统计行数、列数、并支持输出不同格式。先看最经典的实现方式。# csv_stats.py import argparse import csv import sys def parse_args(): parser argparse.ArgumentParser(description统计CSV文件基本信息) parser.add_argument(input_file, help输入的CSV文件路径) parser.add_argument(-o, --output, help输出结果到文件不指定则输出到终端) parser.add_argument(-d, --delimiter, default,, helpCSV分隔符默认逗号) parser.add_argument(--no-header, actionstore_false, desthas_header, helpCSV文件没有表头) return parser.parse_args() def process_csv(file_path, delimiter, has_header): with open(file_path, r, encodingutf-8) as f: reader csv.reader(f, delimiterdelimiter) rows list(reader) if not rows: return None, 文件为空 header rows[0] if has_header else None data_rows rows[1:] if has_header else rows stats { 总行数: len(rows), 数据行数: len(data_rows), 列数: len(rows[0]), 表头: header, } return stats, None def main(): args parse_args() stats, err process_csv(args.input_file, args.delimiter, args.has_header) if err: print(f错误: {err}, filesys.stderr) sys.exit(1) if args.output: with open(args.output, w) as f: for k, v in stats.items(): f.write(f{k}: {v}\n) else: for k, v in stats.items(): print(f{k}: {v}) if __name__ __main__: main()这段代码虽简单但已经体现了CLI工具的三大核心原则清晰的参数界面、分离的逻辑函数、以及健壮的错误处理。argparse自动生成-h帮助文档actionstore_false巧妙处理布尔标志。很多初学者会犯的错误是把所有逻辑写在main()里导致无法单元测试。记住“main函数只负责分发”。第二步进阶——用click装饰器写出更优雅的代码argparse的缺点也很明显参数定义与函数分离代码量偏大。click通过装饰器将参数直接绑定到函数让代码的意图变得无比清晰。看同样的功能用click怎么写# csv_stats_click.py import click import csv click.command() click.argument(input_file, typeclick.Path(existsTrue)) click.option(-o, --output, typeclick.Path(), help输出文件) click.option(-d, --delimiter, default,, show_defaultTrue, helpCSV分隔符) click.option(--no-header, is_flagTrue, helpCSV没有表头) def main(input_file, output, delimiter, no_header): 统计CSV文件基本信息行数、列数、表头等 with open(input_file, r, encodingutf-8) as f: reader csv.reader(f, delimiterdelimiter) rows list(reader) if not rows: click.echo(文件为空, errTrue) return header rows[0] if not no_header else None data_rows rows[1:] if not no_header else rows stats { 总行数: len(rows), 数据行数: len(data_rows), 列数: len(rows[0]), 表头: header, } if output: with open(output, w) as f: for k, v in stats.items(): f.write(f{k}: {v}\n) else: for k, v in stats.items(): click.echo(f{k}: {v}) if __name__ __main__: main()对比argparse版本click的代码量减少了约40%而且参数类型会自动校验click.Path(existsTrue)会在参数无效时报错。click最强大的地方在于它对“子命令”的原生支持——想象一个工具叫data-tool下面有csv、json、yaml等子命令用click.group可以轻松实现。不过click也有其代价装饰器过多时调试比较困难而且对类型提示不够友好。这时就该typer登场了。第三步现代派——用typer写出带类型提示的CLI工具typer建立在click之上但大量利用了Python的类型注解来减少样板代码。上面的例子用typer写几乎是“秒杀”风格# csv_stats_typer.py import csv from typing import Optional import typer app typer.Typer() app.command() def stats( input_file: str typer.Argument(..., help输入的CSV文件路径), output: Optional[str] typer.Option(None, help输出文件), delimiter: str typer.Option(,, helpCSV分隔符), no_header: bool typer.Option(False, --no-header, helpCSV没有表头), ): 统计CSV文件基本信息 with open(input_file, r, encodingutf-8) as f: reader csv.reader(f, delimiterdelimiter) rows list(reader) if not rows: typer.echo(文件为空, errTrue) raise typer.Exit(code1) header rows[0] if not no_header else None data_rows rows[1:] if not no_header else rows typer.echo(f总行数: {len(rows)}) typer.echo(f数据行数: {len(data_rows)}) typer.echo(f列数: {len(rows[0])}) typer.echo(f表头: {header}) if output: with open(output, w) as f: f.write(f总行数: {len(rows)}\n) f.write(f数据行数: {len(data_rows)}\n) f.write(f列数: {len(rows[0])}\n) f.write(f表头: {header}\n) if __name__ __main__: app()typer通过函数签名自动推断参数是必须的还是可选的typer.Argument(...)表示必选位置参数typer.Option(None)表示可选选项。最令人惊艳的是错误输出——当参数类型不对时typer会打印出带颜色和位置提示的错误消息这比click的死板报错更友好。第四步构建可安装的包——让用户用pip install就能装你的CLI仅仅有一个.py文件是不够的真正专业的CLI工具应该可以像pip install my-tool一样安装然后系统里多出一个全局可用的命令。你需要一个setup.py或pyproject.toml。以下是现代推荐的方式pyproject.tomlsetuptools# pyproject.toml [build-system] requires [setuptools61.0, wheel] build-backend setuptools.build_meta [project] name csv-tool version 0.1.0 description 一个用于CSV文件统计的命令行工具 requires-python 3.8 dependencies [ click8.0, ] [project.scripts] csv-tool csv_tool.main:cli # 注意这里指向你的入口函数 [tool.setuptools.packages.find] include [csv_tool]假设你的代码放在csv_tool/目录下csv_tool/__init__.py可以为空csv_tool/main.py中包含你的cli函数用click.group或app。然后运行pip install -e .就可以在终端直接调用csv-tool命令了。最重要的是入口点[project.scripts]决定了用户调用的命令名和对应的函数。如果你用typer入口函数应该是一个typer.Typer()实例比如app()。第五步健壮性不是可选项——错误处理与日志CLI工具最讨厌的行为就是“静默失败”或“打印一堆traceback”。所有面向用户的输出都应该是人性化的。我有几条铁律所有异常都必须被捕获并给出清晰解释。比如文件不存在直接提示用户检查路径而不是FileNotFoundError。使用sys.exit(1)或raise typer.Exit(code1)表明非零退出码。管道命令依赖退出码判断成功与否。标准输出和标准错误严格分离正常结果打印到stdout错误和诊断信息打印到stderr。这样用户可以把正常结果重定向到文件而错误依然在终端显示。例如上面例子中click.echo(文件为空, errTrue)就是打印到stderr。如果你用argparse可以print(错误信息, filesys.stderr)。另外日志模块logging在CLI中非常有用。一般设计是默认只输出WARNING及以上级别用户可以通过-v或--verbose设置DEBUG。我通常这样封装import logging def setup_logging(verbose: int): level logging.DEBUG if verbose 0 else logging.WARNING logging.basicConfig(format%(levelname)s: %(message)s, levellevel)然后在主函数中根据verbose参数调用。第六步让CLI支持管道和重定向——遵循Unix哲学好的CLI工具应该能够与其他命令优雅组合。这意味着你的工具必须能接受标准输入当文件参数省略时并且输出格式要可以被后续命令解析。比如我们可以让csv-tool stats支持从管道读入数据click.command() click.argument(input_file, typeclick.Path(existsTrue), requiredFalse) def stats(input_file): 从文件或stdin读取CSV并统计 if input_file: f open(input_file, r, encodingutf-8) else: f sys.stdin # 直接用标准输入 # ... 处理逻辑 ...这是一个巨大的设计决策因为一旦支持stdin你的工具就变成了“过滤式”命令可以放在管道中间。比如cat data.csv | csv-tool stats。如果你还支持--json输出则可以用jq进一步处理。第七步测试你的CLI——从手动敲命令到自动化验证测试CLI工具有几种常用方法。最简单的是使用subprocess在测试中实际运行你的脚本并检查输出。但更高效的做法是利用click.testing.CliRunner也支持typer——它不需要真的启动新进程而是在内存中模拟调用。# test_csv_tool.py from click.testing import CliRunner from csv_tool.main import cli def test_stats_basic(): runner CliRunner() # 创建一个临时CSV文件 with runner.isolated_filesystem(): with open(test.csv, w) as f: f.write(a,b,c\n1,2,3\n4,5,6\n) result runner.invoke(cli, [stats, test.csv]) assert result.exit_code 0 assert 总行数: 2 in result.output assert 列数: 3 in result.outputrunner.isolated_filesystem()会创建一个临时目录测试结束后自动删除非常干净。你也可以测试错误场景比如不存在的文件应该返回非零退出码。第八步构建“智能”帮助信息——让用户不需要阅读文档一个真正优秀的CLI工具其帮助文档本身就是最好的用户手册。不要满足于自动生成的-h输出而是要精心设计描述文本。click和typer都支持在装饰器中添加help参数甚至支持导览示例epilog。例如click.command(epilog使用示例:\n csv-tool stats data.csv --no-header\n csv-tool stats data.csv -o result.txt) def stats(): ...我见过很多CLI工具参数名用单字母缩写但从不解释用户不得不猜。每一行帮助都应该回答“这个参数的作用”和“默认值是什么”。click的show_defaultTrue是个好习惯。第九步打包成单一可执行文件——无Python环境也能用当你写完CLI工具想让没有安装Python的同事也能使用可以选择打包成独立的可执行文件。常用工具有PyInstaller和Nuitka。以PyInstaller为例在项目根目录运行pip install pyinstaller pyinstaller --onefile --name csv-tool csv_tool/main.py生成的单一可执行文件在dist/csv-toolWindows下是csv-tool.exe大小约几MB。注意--onefile会打包Python解释器和依赖启动速度稍慢但分发方便。如果你想支持不同操作系统需要在对应的系统上分别打包交叉编译困难。第十步高级技巧——交互式CLI与进度条当你的CLI工具处理耗时较长的任务时静态输出远远不够。用户需要知道进度。我们可以用click.progressbar或第三方库rich的Progress来实现。比如读取大文件时显示行数import click with click.progressbar(lengthtotal_lines, label处理中) as bar: for line in file: # 处理一行 bar.update(1)更现代的方案是用rich库它不仅能显示进度条还能输出带颜色和表格的漂亮终端界面。例如from rich.progress import Progress, BarColumn, TextColumn import time with Progress(TextColumn([progress.description]{task.description}), BarColumn(), TextColumn({task.percentage:3.0f}%)) as progress: task progress.add_task([green]下载中..., total100) for i in range(100): progress.update(task, advance1) time.sleep(0.1)这样的交互体验会让你的CLI工具在同类中脱颖而出。记住用户的耐心是有限的进度条是对用户时间的尊重。总结从脚本到工具只差这十步我们走完了从零开始构建Python CLI工具的完整路径先选一个库argparse/click/typer然后设计参数、分离逻辑、添加错误处理、支持管道、编写测试、打包分发。最后的成品不再是“一个.py文件”而是一个可安装、可测试、可协作的软件工程产物。现在如果你还在用sys.argv写CLI不妨今天就开始重构。把每次的手动操作变成可复用的命令把散落在各个脚本里的逻辑收集成体系化的工具。当你的同事说“能不能帮我跑个数据”你只需要回答“你装一下这个包运行my-tool process就行”时你就真正掌握了Python CLI开发的精髓。下一步可以探索如何让你的CLI支持插件化动态加载子命令、如何实现自动补全shell completion、以及如何用asyncio做异步CLI。但这些已经是进阶话题了。先动手做一个你自己的工具吧——从今天开始。
