可以通过多种方式将参数传递给 Java 应用程序。其中有：
properties-style)-D 选项传递）从意识形态上讲，什么时候应该更喜欢一个而不是另一个？ 例如，如果有很多参数要传递给应用程序，是否有任何理由支持命令行参数而不是 *.properties 文件？
或者，例如，可以从堆栈深处的任何类轻松访问系统变量（与 CLI 不同，CLI 只能在 main 中访问）。是否应该仅仅因为易于访问而更喜欢使用系统属性而不是 CLI？
【问题讨论】：
标签： java command-line-interface command-line-arguments ini
取决于部署需要回答其中的一些问题。
命令行参数：当您有其他进程生成您的应用程序并且您想从调用进程控制这些参数时，这很好。一个例子是 CRON 产生它。
文件：我不喜欢 ini 风格......你被困在 Windows 上。如果您想要一些非常简单的东西，请首选可以使用 Properties 类加载的 .properties 文件。或者您可以使用 XML。文件还可以让您选择文件位置，相对于应用程序而言，部署非常好，有些人还喜欢将它们扔到全局的某个地方，例如 /etc
环境变量：它们有它们的位置，尽管它使部署更加复杂。如果环境影响您的应用程序的参数，我只会使用它。这意味着，您的应用程序的行为会有所不同，或者需要根据操作系统、机器等进行不同的配置。
偏好是主观的，可能取决于应用程序、部署、系统等的类型。
【讨论】：
嗯，说到配置，每个程序员对如何做正确的方法都有自己的想法……像往常一样，这取决于很多事情。
我习惯以这种方式处理这种选择：如果它类似于环境变量（类似于 $PATH 或 $SHELL），并且可以/必须由调用者设置（另一个程序或启动脚本） ，它通过 -D 开关直接进入 System.Properties。
如果是别的东西，那么它直接进入属性文件（实际上它的加载方式并不重要，有几种方法可以做到这一点，每种方法都有利弊，我最喜欢的是从类路径加载，但只是口味问题）。
我尽量在 System.Properties 中保留最小的、非常重要的东西，如果它是一个大配置，最好使用 Properties 或 XML 甚至更好的数据库表，但同样，这取决于你的应用程序的复杂性（HelloWorld 带有DB 简直是矫枉过正^^)。
【讨论】：