Java main方法的args数组接收命令行中java命令与类名之后所有空白分隔的字符串，原样存入String[]，不做解析或类型转换；引号仅在shell层作用，Java中仅保留字符串内容，空格为唯一分隔符，连续空格被shell合并，args为空数组合法，访问前须检查length，勿用==null判空，跨平台行为一致但shell解析有差异，类型转换需校验并捕获异常，建议用命名参数提升可维护性。
Java main 方法的 args 数组到底接收什么
它只接收命令行中 java 命令之后、类名之后的所有空白分隔的字符串，原样存进 String[]，不做任何解析或类型转换。
比如运行：java MyApp -u admin --port 8080 "hello world"，args 就是：["-u", "admin", "--port", "8080", "hello world"] —— 注意引号只在 shell 层起作用，进到 Java 里只剩一个字符串元素。
- 空格是唯一分隔符，制表符、换行符不会被当作分隔符（shell 已处理）
- 连续多个空格会被 shell 合并为一个分隔，Java 看不到“空参数”
-
args为空数组[]是合法的，不代表出错，只是没传参 - 如果想传含空格的值（如路径
/opt/my app/config.txt），必须用引号包裹，否则会被拆成两个参数
常见错误：为什么 args[0] 报 ArrayIndexOutOfBoundsException
因为忘了检查长度，直接访问 args[0]。Java 不会自动补默认值，也不会跳过缺失参数。
典型翻车场景：本地测试时加了参数，但打包后运行脚本漏写了，或者 CI 环境未配置，一执行就崩。
立即学习“Java免费学习笔记（深入）”；
- 永远先判断
args.length > 0再取args[0] - 不要用
args[0] == null判空——数组元素不可能为null，空字符串""和null是两回事 - 如果依赖固定位置参数（如
args[0]是文件路径），建议改用--file=xxx这类命名参数，配合简单解析（哪怕手写for循环遍历）
Windows 和 macOS/Linux 下传参行为一致吗
Java 层面完全一致；差异全在 shell 解析阶段，不是 JVM 的问题。
Windows cmd.exe 对引号和转义的支持弱于 bash/zsh，比如 java MyApp "a b" "c^&d" 在 cmd 中 ^& 可能被提前解释，而 bash 里 & 或单引号更可靠。
- 跨平台脚本中，避免使用
&、|、<、>等 shell 元字符作为参数值，除非你明确控制执行环境 - 路径类参数优先用正斜杠
/（JavaFile.separator兼容），避免 Windows 风格反斜杠引发转义问题（如"C:configpp.conf"会被当作文本C:configpp.conf） - 用
System.getProperty("os.name")做系统判断是可行的，但别用来决定参数格式——参数格式应由调用方保证，Java 只负责消费
怎么安全地把 args 转成真正需要的类型
别信 Integer.parseInt(args[1]) 这种裸调用，生产代码必须包 try-catch，且要有明确错误提示。
例如端口号参数，用户输错成 abc 或负数，直接抛异常不如打印一行友好的提示再退出。
- 数字转换前先用
args[i].matches("\d+")快速过滤非数字（注意负数要单独处理） - 布尔型别靠字符串相等判断
"true"/"false"，建议统一接受"on"/"off"或"yes"/"no"，忽略大小写 - 避免在
main里写复杂逻辑，可提取为parseArgs(String[] args)方法，返回一个简单配置对象，让业务逻辑只跟对象打交道 - 如果参数变多（>4 个），立刻停手，引入
picocli或Apache Commons CLI——手写解析器维护成本远高于加一个依赖
最常被忽略的是：参数顺序依赖一旦固化，后续加新参数就容易错位。命名参数（--timeout=30）比位置参数（30）容错高得多，哪怕只多写几个字符。
