生产服务里，环境变量和命令行参数到底该怎么用？
在做后端服务、桌面端本地服务、sidecar 子进程这类系统时，经常会遇到一个问题：父进程启动子进程时，到底应该用环境变量传配置，还是用命令行参数传配置？
很多项目一开始都会直接用环境变量。它方便、简单、跨语言，而且 Node、Python、Rust、Go 都能轻松读取。但随着系统进入生产形态，环境变量如果滥用，很容易让运行路径变得不可控。
这篇文章聊一个通用原则：
生产路径由显式启动参数或配置文件决定，环境变量只作为开发、调试和运维覆盖手段。
什么是 argv？
argv指的是程序启动时收到的命令行参数。
比如：
node sidecar.js --ipc-mode=uds --socket-path=/run/app/sidecar.sock --storage-path=/var/lib/app/storage在 Node.js 里可以通过：
console.log(process.argv)读取这些参数。
在 Rust 里也可以通过 clap、std::env::args 等方式解析。
什么是 env？
env指的是环境变量。
比如：
IPC_MODE=uds SOCKET_PATH=/run/app/sidecar.sock node sidecar.js在 Node.js 中读取：
const socketPath = process.env.SOCKET_PATH;在 Rust 中读取：
let socket_path = std::env::var("SOCKET_PATH").ok();两者都能传配置，但语义不同。
env 和 argv 的核心区别
环境变量更像“进程周围的空气”。
它来自 shell、系统服务、CI、容器、父进程，也可能来自用户本机已有配置。只要进程启动时继承了这片环境，程序就能读到它。
命令行参数更像“这次启动明确给这个程序的指令”。
它直接出现在启动命令里，通常只作用于当前进程，而且语义更局部、更清楚。
简单对比：
| 方式 | 适合场景 | 风险 |
|---|---|---|
| env | 密钥、调试开关、CI/CD 注入、临时覆盖 | 容易被外部环境污染，来源不够显式 |
| argv | 本次启动所需的普通配置，如路径、模式、端口 | 参数过多时需要结构化管理 |
| config file | 复杂配置、可持久化配置、用户可编辑配置 | 需要管理配置版本和默认值 |
一个常见问题：生产路径不应该靠 env 决定
假设有一个主服务会启动一个 sidecar 子进程：
app --workdir=/opt/myapp子进程需要知道三个路径：
/opt/myapp/run/sidecar.sock /opt/myapp/data/storage /opt/myapp/log/sidecar.log如果用环境变量传：
SOCKET_PATH=/tmp/test.sock STORAGE_PATH=/tmp/storage app --workdir=/opt/myapp那么生产运行路径就可能被外部环境改掉。
这会带来几个问题：
- 本来应该写到
/opt/myapp/data，结果写到了/tmp/storage。 - 多实例运行时可能共享同一个 socket 或 storage。
- Debug 环境变量忘记清理后，生产行为被悄悄改变。
- 排查问题时，很难从启动命令看出真实运行路径。
更稳妥的方式是：
app --workdir=/opt/myapp主服务内部根据workdir统一推导路径：
<workdir>/run/sidecar.sock <workdir>/data/storage <workdir>/log/service.log然后启动子进程时用 argv 明确传入：
node sidecar.js \ --ipc-mode=uds \ --socket-path=/opt/myapp/run/sidecar.sock \ --storage-path=/opt/myapp/data/storage这样路径来源就很清楚：都是从--workdir推导出来的。
推荐结构
一个比较清晰的本地服务目录结构可以是：
<workdir>/ run/ sidecar.sock data/ app.db storage/ log/ service.log其中：
run/放运行时临时文件，比如 socket、pid file。data/放持久化数据，比如数据库、storage、cache。log/放日志。config/可选，放用户可编辑配置。
推荐配置优先级
对于生产服务，可以采用下面的优先级：
1. 明确的命令行参数 2. 配置文件 3. 代码默认值 4. 环境变量 fallback，仅用于开发/调试也可以更严格一点：
生产路径：argv/config only 开发调试：env fallback 敏感信息：env 或 secrets manager重点是不要让 env 变成所有配置的默认入口。
什么配置适合继续放 env？
环境变量不是不能用，而是要用在合适的位置。
适合 env 的内容：
NODE_ENV=productionRUST_LOG=infoDATABASE_URL- API key、token、secret
- CI 中的临时参数
- 本地开发的 debug 开关
- 压测或故障排查时的临时调优项
不太适合 env 的内容：
- 应用的工作目录
- 子进程 socket 路径
- 持久化 storage 路径
- 多实例隔离目录
- 产品必须稳定依赖的运行路径
总结
环境变量很方便，但方便不等于适合作为生产路径的核心来源。
更推荐的做法是：
主程序通过 --workdir 明确工作目录 主程序根据 workdir 推导 data/run/log 主程序启动子进程时用 argv 传入必要路径 子进程 argv 优先，env 只作为开发 fallback这样做的好处是：
- 生产路径稳定
- 多实例隔离清楚
- 启动命令可读
- 排查问题更直接
- 环境变量不会悄悄改变产品行为
一句话总结：
env 适合表达外部运行环境，argv 适合表达进程启动的明确意图。
