第一次在服务器上部署 Java 应用的时候我被环境变量坑得怀疑人生。明明export JAVA_HOME的时候路径好好的关掉终端再打开就全没了明明脚本里写了$1加了引号却传不进去参数。后来踩的坑多了才想明白命令行参数和环境变量就是 Linux 进程世界的两个基本功绕不过去但也真没那么玄乎。这篇文章就把我这些年折腾 Linux 的经验捋一遍命令行参数怎么接、环境变量到底存在哪里、改 PATH 为什么老翻车、配 JDK 和 Anaconda 的正确姿势、以及一套排查问题的方法。新手可以直接照着操作老手可以看看有没有你还没遇过的坑。1. 命令行参数与环境变量先分清这两兄弟1.1 它们到底分别是什么很多人把命令行参数和环境变量混在一起学结果一写脚本就乱。其实两者的本质区别非常清楚命令行参数是你调用某个程序时临时告诉它的话环境变量是从父进程继承给子进程的一组全局配置。举个例子。你执行一条命令java -Xmx512m -jar app.jar --port8080这里的-Xmx512m、-jar、--port8080都是命令行参数它们只对这次启动的java进程生效属于一次性信息。而环境变量像是进程从父母那里继承的家底比如PATH、HOME、LANG任何一个子进程都能读得到子进程的子进程也能看到具有天然的传递性。更直接一点理解命令行参数是面对面下的指令环境变量是写在遗传基因里的默认配置。面对面说过的话转身就忘这个进程结束就没了遗传基因里的东西只要出生被 fork 出来就自动带上。1.2 为什么必须区分这两者搞清楚区别不是做理论考试而是直接关系到你到底该把配置放在哪里。命令行参数适合放本次调用才决定的、随调用场景变化的信息比如端口号、文件路径、开关选项。环境变量适合放几乎所有进程都应该知道的、相对固定的系统级配置比如 Java 装在哪、临文件目录在哪、系统语言是什么。我把这俩的关键差异整理成了一张表平时写脚本拿不准时回来看看对比项命令行参数环境变量传递方式调用程序时逐个传入父进程自动传给子进程生命周期随进程结束而消失随进程结束而消失但可通过配置文件固化可见范围只对本次调用的程序可见所有子进程可见天然全局修改方式每次调用时修改export、配置文件、systemd 等典型用途端口、路径、功能开关PATH、JAVA_HOME、LANG、代理配置调试手段echo $1、shiftenv、printenv、export -p这个区分直接决定了你怎么排查问题。如果脚本报错找不到命令优先查环境变量如果脚本报错参数不对优先查命令行参数是怎么传进来的。方向对了排障时间至少省一半。2. 命令行参数解析从 $1 到 getopt 的进化之路2.1 基本功位置参数和特殊变量Shell 脚本里接参数最底层的招数就是位置参数。$1是第一个参数$2是第二个以此类推$0是脚本自身的名字。$#是参数个数$是所有参数的列表$*也是所有参数但会被当成一个字符串。我见过不少新人在这个地方翻车最典型的场景是路径里有空格#!/bin/bash # 错误示范文件名带空格时 $1 只能拿到前半截 cp $1 /backup/ # 正确示范必须加引号保护 cp $1 /backup/如果你传进来的是my document.pdf不加引号时$1只会拿到mydocument.pdf被当成第二个参数。这种问题在命令行交互时不容易暴露因为 Tab 补全会帮你转义但脚本里没人替你转义。记住一条铁律凡是用了位置参数的地方一律用双引号包住。另一个高频需求是给参数设默认值。用${1:-默认值}这种写法#!/bin/bash PORT${1:-8080} echo 启动端口: $PORT${1:-8080}的意思是如果$1没传或为空就用8080。这个语法比if [ -z $1 ]判断要简洁得多我写的部署脚本里几乎每个参数都这么处理。2.2 shift 和循环批量消费参数有些脚本需要处理不定数目的参数比如批量文件名。这时候shift就派上用场了它的作用是把参数列表整体左移一位原来的$2变成$1原来的$3变成$2以此类推。#!/bin/bash while [ $# -gt 0 ]; do echo 处理文件: $1 shift done这段循环每次取走当前$1然后 shift 一下直到把参数列表消费完。我有一次写批量转码脚本就是靠这个思路把几十个视频文件一次性丢进去循环里逐个调用 ffmpeg 处理。需要说明的是shift可以带数字参数比如shift 2表示一次跳过两个参数。这在解析成对参数俗称 key-value 参数时特别方便--name zhangsan这种格式先取--name再取zhangsan读完直接shift 2跳过。2.3 getopts正规军的短选项解析如果脚本的选项多起来手写解析会非常痛苦。-h、-v、-f file、-d这种短选项组合就得上getopts了。#!/bin/bash while getopts hf:d opt; do case $opt in h) echo 帮助信息-f 指定文件-d 启用调试 exit 0 ;; f) FILE$OPTARG ;; d) DEBUGtrue ;; *) echo 不支持的选项 exit 1 ;; esac donegetopts后的字符串是选项定义hf:d表示支持-h、-f后面必须跟值、-d。冒号表示这个选项需要一个参数值这个值会存到$OPTARG里。注意getopts和系统里另一个命令getopt不是一回事。getopts是 Bash 内建命令只支持短选项getopt是外部命令支持 GNU 长选项解析。如果你需要--file xxx这种长选项格式要么用getopt要么干脆自己写 case 分支。我一般倾向写 case 分支因为可读性好别人维护起来不费劲。2.4 一个实际部署脚本的完整参数设计把前面这些技巧串起来给你看一个我实际在用的部署脚本片段#!/bin/bash # 用法: deploy.sh [-p 端口] [-e 环境] [-d] PORT${1:-8080} ENVprod DEBUGfalse while getopts p:e:d opt; do case $opt in p) PORT$OPTARG ;; e) ENV$OPTARG ;; d) DEBUGtrue ;; *) echo 用法: $0 [-p 端口] [-e 环境] [-d]; exit 1 ;; esac done echo 部署到 $ENV 环境端口 $PORT [ $DEBUG true ] echo 调试模式开启这个脚本的每一步都有讲究先用${1:-8080}做默认值兜底再用getopts解析具名选项最后通过[ $DEBUG true ]控制分支逻辑。这样设计出来的脚本既能./deploy.sh裸跑又能./deploy.sh -p 9090 -e staging精细控制还保留了-d调试开关避免了改脚本才能调参数的低效操作。3. 环境变量的生命周期从 export 到配置文件3.1 export 只是临时措施很多新手以为export PATH/usr/local/jdk/bin:$PATH之后就一劳永逸了然后第二天打开服务器发现命令全找不到了。这个坑我见过太多次。export的作用仅仅是在当前这个 shell 进程中标记这个变量让它的子进程也能看到。这个 shell 一关变量就跟着没了。要想让变量持久生效必须把 export 写进 shell 的启动配置文件里。Linux 下常见的配置文件有这几个它们的加载时机和场景完全不同配置文件加载时机适用场景/etc/profile登录 shell 启动时系统级全局配置/etc/profile.d/*.sh登录 shell 启动时按功能拆分的系统级配置推荐用这个~/.bash_profile用户登录 shell 启动时单个用户的登录配置~/.bashrc交互式非登录 shell 启动时单个用户的每次终端配置/etc/environmentPAM 登录时系统级需要最早期生效的全局变量这里有个容易搞混的点你在本地 Ubuntu 上开终端通常加载的是~/.bashrc而不是~/.bash_profile。因为桌面版终端默认是交互式非登录 shell。但如果你用 SSH 远程登录先加载的是~/.bash_profile。所以经常出现本地配好了SSH 上去就没有的情况。我的建议是用户级的环境变量统一写进~/.bashrc再从~/.bash_profile里 source 一下~/.bashrc。很多发行版默认就是这么配置的不用额外操心。3.2 PATH 的拼接与覆盖陷阱PATH是环境变量里最常被动的也是最容易改出问题的。正确写法export PATH/usr/local/bin:$PATH错误写法export PATH/usr/local/bin第二种写法的后果是新路径覆盖了原来的PATH系统命令全部找不到连ls、vim都没了。你只能靠绝对路径/bin/ls找回一点尊严然后老老实实把变量改回去。拼接时还有个顺序问题。路径放前面优先找到你新装的版本路径放后面系统默认版本优先。比如服务器上自带了旧版 Python 在/usr/bin/python3你在/usr/local/bin又装了个新版想让python3指向新版就得把新路径放前面。另外要警惕重复拼接。每次执行export PATH/usr/local/bin:$PATH变量里就多一份/usr/local/bin。有人终端开多了PATH里同一个路径出现十几遍虽然不影响功能但看着难受排查问题也容易混乱。干净的写法是启动时先判断case :$PATH: in *:/usr/local/bin:*) ;; *) export PATH/usr/local/bin:$PATH ;; esac这个写法用:包裹整个$PATH做模式匹配避免了重复项。3.3 环境变量的作用域与可见性环境变量看起来是全局的但它其实只向下传递不向上回传。父进程设置了变量并 export子进程能看到子进程改了变量父进程完全无感知。这带来一个很实际的坑你在终端里export了一个变量然后在同一个终端里启动的服务能看到它但如果服务是由 systemd 启动的它不会读你的 shell 变量它有自己的环境配置。现代服务管理用 systemd 时正确的配环境变量方式是写在 service 文件里[Service] EnvironmentJAVA_HOME/usr/lib/jvm/java-17-openjdk-amd64 EnvironmentAPP_OPTS--server.port8080或者用EnvironmentFile指向一个配置文件集中管理。我之前把一个应用从supervisord迁到 systemd 时就因为在 shell 里 export 的变量没有生效排查了很久才发现是因为 systemd 压根不经过 shell。还有一个隐藏场景需要留意环境变量的值里如果有空格或特殊字符在配置文件里务必加引号。比如MY_VARhello world # 正确 MY_VARhello world # 错world 会被当成另一条命令4. 高频实战配置JDK、Anaconda 与常见工具4.1 Java 环境变量配置的完整流程配 Java 算是环境变量领域最经典的操作了。在 Linux 上核心就是三个变量JAVA_HOME、PATH、CLASSPATH。以 OpenJDK 17 为例先确认安装路径# 用包管理器安装时一般会自动配置好 which java ls -l /usr/bin/java如果java命令能找到但JAVA_HOME没配可以这样定位真实路径readlink -f /usr/bin/javareadlink -f会递归解析所有软链接从/usr/bin/java一路追到 JDK 的真实安装目录。结果类似/usr/lib/jvm/java-17-openjdk-amd64/bin/java去掉末尾的/bin/java/usr/lib/jvm/java-17-openjdk-amd64就是JAVA_HOME的值。然后在~/.bashrc末尾追加export JAVA_HOME/usr/lib/jvm/java-17-openjdk-amd64 export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib最后执行source ~/.bashrc让配置立即生效再用java -version和echo $JAVA_HOME验证。关于CLASSPATH我多说一句现代 Java 开发基本不用设置这个变量了Maven、Gradle 都会自己管理 classpath。老教程里让配CLASSPATH是历史遗留习惯配了也无妨但别指望它能解决什么问题。我见过有人往CLASSPATH里塞了一堆 jar 路径结果不同项目的依赖互相打架改成一个空值带当前目录的兜底配置才好。4.2 Anaconda 环境变量的正确设置Anaconda 的安装器会自动往~/.bashrc里写入一段 PATH 配置并把 conda 的初始化代码加进去。但很多人自定义安装路径后这段配置没生效会导致conda命令找不到。如果手动配置核心就一句话export PATH/home/你的用户名/anaconda3/bin:$PATH然后source ~/.bashrc再执行conda --version确认。这里有个常见的争执到底把 conda 的路径加到 PATH 前面还是后面Anaconda 官方推荐放前面因为 conda 管理的 Python 版本优先级压制系统自带的/usr/bin/python3。但如果你不想影响系统里依赖旧 Python 的工具就不要加而是每次需要时手动conda activate。我的习惯是日常使用可以放前面但服务器上跑系统服务的机器不放。有一次我在一台生产服务器上装了 Anaconda没注意 PATH 顺序结果系统自带的yum实际是 Python 脚本开始用 conda 的 Python 跑直接报了一堆依赖错误。那次教训让我给所有生产服务器立了规矩Anaconda 只给数据分析专用的账号配置系统账户一概不动。4.3 用 env 和 printenv 验证配置配置完之后验证是必不可少的一步。推荐的验证命令# 查看单个变量 printenv JAVA_HOME # 查看所有变量 env | sort # 检查 PATH 中实际可用的命令 which java which conda为什么要用printenv而不是echo $JAVA_HOME两者大部分情况效果一样但printenv更规范而且当变量名不存在时不会因为展开空值造成误判。另外env适合检查整体环境配合sort可以快速扫一遍有没有异常项。如果你配完了发现which java指向的还是旧路径八成是 PATH 顺序问题。直接打印echo $PATH看看新路径在不在前面。这块排查逻辑其实就三步变量值对不对、配置文件加载没、PATH 顺序对不对。5. 实操中的疑难杂症与排查手册5.1 环境变量不生效的三种情况配置写完source ~/.bashrc之后发现不生效我总结出最常见的三类原因第一改错了文件。用户是交互式 shell配置文件在~/.bashrc但脚本环境或者 systemd 服务根本不走这个文件。脚本里要用环境变量必须在脚本开头显式 export或者通过set -a让所有变量自动导出。第二终端复用问题。你开了一个旧终端里面还保留着 source 之前的变量快照新配置自然不会自动出现。最直接的解法就是开个新终端或者重新执行source ~/.bashrc。第三语法错误导致整个文件中断。配置文件里如果某一行有语法问题bash 会在解析到那里时报错后面的行全部不执行。排查方法是用bash -x调试模式跑一遍bash -x ~/.bashrc-x会把每一步展开后的命令打出来错误一目了然。这是我最常用的诊断手段比瞪大眼睛找引号管用多了。5.2 环境变量配置错误的系统级自救如果你改坏了/etc/profile或者/etc/environment导致所有用户登录后命令都找不到这时候千万别慌也别关 SSH 窗口。正确的自救姿势是用绝对路径打开编辑器修复/bin/vim /etc/profile如果连 vim 都不在 PATH 里用/usr/bin/vim再不行就用/bin/sed直接把错误行删掉/bin/sed -i /错误的内容/d /etc/profile修复后再用source /etc/profile重新加载。我吃过一次亏改了/etc/profile后直接重启了服务器结果 SSH 连上来连sudo、ls都没有只能通过云厂商的控制台接口进去。从那以后凡是改系统级环境变量文件我都会先备份一份然后开两个终端一个改一个待命改坏了立刻用备份恢复。5.3 命令行参数相关的经典翻车现场参数解析的问题不像环境变量那么隐蔽而且报错往往更明显但有几个点还是值得单独拿出来说。第一个是通配符展开的时机。你把*.log传给脚本如果脚本里echo $1会打出/tmp/a.log /tmp/b.log这样一个合并字符串而不是两个单独参数。因为 shell 会在传给脚本之前就把通配符展开成多个参数了。但如果你用了引号*.log看到的就还是字面量*.log。理解这个时机差异脚本里循环处理文件列表时才不会出错。第二个是空参数的处理。调用脚本时传了两个引号表示一个空参数$2能看到但值为空。用${2:-默认值}会把它当成默认值处理用${2:默认值}则能保留空字符串。这两个运算符的区别看似细微但涉及数据完整性时不能马虎。第三个坑是 Windows 环境下的 CRLF 换行符。Windows 里写的脚本传到 Linux 上跑如果每行结尾带着\r参数比较会莫名失败。用cat -A script.sh能看到行尾是不是有^M标记有就执行sed -i s/\r$// script.sh去掉。这个问题在混合环境开发时几乎是必现的提前处理能省掉大量无谓的排查时间。5.4 一张排查速查表依赖经验累积我把最常遇到的环境变量和命令行参数问题做成一张速查表遇到可以直接对照现象可能原因优先排查方法java: command not foundPATH 没包含 JDK bin 目录echo $PATH确认$JAVA_HOME/bin在前脚本里命令找不到脚本环境没有继承 PATH脚本开头加export PATH$PATH:/usr/local/binconda: command not foundAnaconda 路径没加进 PATHls ~/anaconda3/bin/conda看路径对不对配了变量但进程看不到子进程范围或 systemd 环境隔离用tr \0 \n /proc/进程pid/environ查参数带空格被截断位置参数未加引号所有$1、$加双引号传参数量不对通配符展开或多空格在脚本里echo $#看实际参数个数执行脚本报bad interpreterCRLF 换行符问题cat -A script.sh查^M关于/proc/pid/environ这个查法值得展开说一句。它打印的是进程启动那一刻的环境变量快照中间用\0分隔所以需要用tr \0 \n转成每行一个变量。我之前排查一个 daemon 进程为什么读不到配置就是用这个命令发现它压根不是从 shell 启动的环境差异一目了然。6. 我的一些实操心得写了这么多其实最想分享的经验就几条。第一配置环境变量之前永远先备份。cp ~/.bashrc ~/.bashrc.bak这一行代码成本几乎为零但出了问题能救你一条命。系统级文件更是如此。第二尽量别在全局配置里塞个人变量。我习惯把与具体用户相关的配置全放~/.bashrc只有所有用户都必须用的系统级变量才放进/etc/profile.d/而且一个变量一个文件命名清晰出问题好定位。这比把所有配置堆到/etc/profile里要优雅得多。第三命令行参数和 shell 脚本的防御性编程很重要。我给脚本写参数处理时默认每一位使用者都可能传错参数所以默认值、参数个数校验、引号保护一个都不能少。脚本写得糙当时跑得欢三个月后维护的就是自己头上长草。最后分享一个调试小技巧在脚本开头直接打印收到的参数和环境状态很多问题其实一眼就能看出来#!/bin/bash echo 脚本名称: $0 echo 收到参数个数: $# echo 所有参数: $ echo 当前 PATH: $PATH echo 当前用户: $(whoami)这行调试代码我几乎每个新脚本都会先加上确认无误后再删掉。Linux 的命令行参数和环境变量说到底就是进程交接信息的两种方式。理解了它们的生命周期和作用范围配合一套规范的配置流程你踩过的坑会越来越少写的脚本也会越来越稳。