我基本上同意之前的答案，但有另一个重要方面：
可用性。
例如，在
git中，您可以创建一个存储库，并将
.git目录放在外部。要指定它，可以使用命令行参数
--git-dir或环境变量
GIT_DIR。
当然，如果你将当前目录更改为另一个存储库或在脚本中继承环境变量，就会出现错误。但是，如果您需要在一个终端会话的分离存储库中键入多个
git命令，则这非常方便：您不需要重复
git-dir参数。
另一个例子是
GIT_AUTHOR_NAME。似乎它甚至没有一个命令行伙伴（但是，
git commit有一个
--author参数）。
GIT_AUTHOR_NAME覆盖了
user.name和
author.name配置设置。
总的来说，在UNIX上使用命令行或环境参数同样简单：可以使用命令行参数。
$ command --arg=myarg
或者在一行中使用环境变量：
$ ARG=myarg command
在alias中，捕获命令行参数也很容易：
alias cfg='git --git-dir=$HOME/.cfg/ --work-tree=$HOME'
alias grep='grep --color=auto'
一般而言，大多数参数都是通过命令行传递的。我同意之前的答案，这种方式更加实用和直接，脚本中的环境变量就像程序中的全局变量一样。
GNU libc 表示：
argv 机制通常用于传递特定于被调用程序的命令行参数。另一方面，环境跟踪由许多程序共享、不经常更改且较少使用的信息。
除了关于环境变量危险性的说法外，它们还有很好的用例。
GNU make 对环境变量有非常灵活的处理方式（因此与 shell 非常集成）：
make 启动时看到的每个环境变量都会转换为具有相同名称和值的 make 变量。但是，在 makefile 中或使用命令参数进行显式赋值会覆盖环境变量。（-- 并且有一个选项来更改此行为）...
因此，通过在您的环境中设置变量CFLAGS，您可以使大多数makefile中的所有C编译都使用您喜欢的编译器开关。对于具有标准或常规含义的变量来说，这是安全的，因为您知道没有任何makefile会将它们用于其他事情。
最后，我要强调的是，对于一个程序来说，最重要的不是程序员，而是用户体验。也许您已经将其包含在设计方面了，但内部和外部设计是非常不同的实体。
关于编程方面，我想说几句。您没有写明使用哪种语言，但我们可以想象您的工具允许您进行最佳的参数解析。在Python中，我使用
argparse，它非常灵活且功能丰富。要获取解析的参数，可以使用类似以下的命令：
args = parser.parse_args()
args可以进一步分解为已解析的参数（例如
args.my_option），但我也可以将它们作为整体传递给我的函数。如果您的语言允许，这种解决方案绝对不会“难以维护大量参数”。实际上，如果您有许多参数，并且它们在参数解析期间未被使用，请将它们传递到容器中，以避免代码重复（这会导致不灵活性）。
最后的评论是，解析环境变量比命令行参数容易得多。环境变量只是一对
VARIABLE=value。命令行参数可能更加复杂：它们可以是位置参数或关键字参数，也可以是子命令（例如
git push）。它们可以捕获零个或多个值（请回想一下命令
echo和像
-vvv这样的标志）。有关更多示例，请参见
argparse。
还有一件事。你对内存的担忧有点令人不安。不要编写泛泛而谈的程序。库应该是灵活的，但是一个好的程序应该没有任何参数就可以使用。如果需要传递大量内容，这可能是数据，而不是参数。如何将数据读入程序是一个更为普遍的问题，没有适用于所有情况的单一解决方案。
