Linux systemd service 环境变量怎么只对单个服务生效

想让一个 Linux 服务读取 APP_MODE=staging，关键是把变量写进这个服务自己的 unit 配置，而不是写到全局 shell、/etc/environment 或 systemd manager 的默认环境里。最稳妥的做法是使用 systemctl edit order-api.service 创建 drop-in，在 [Service] 段添加 Environment= 或 EnvironmentFile=，然后重载并重启目标服务。

服务级变量的边界由 unit 名称决定：order-api.service 的 drop-in 只参与这个 unit 的进程环境组装。其他服务不会因为它读取了同一个文件而自动继承这些变量。

先把变量放进目标 unit 的边界

假设服务名为 order-api.service。执行下面的命令会打开该服务的 drop-in；保存后 systemctl 会重新加载 unit 配置。

# 只编辑 order-api.service 的覆盖片段
sudo systemctl edit order-api.service

写入以下内容：

[Service]
# 只给订单服务设置运行模式，不影响其他 unit
Environment="APP_MODE=staging" "LOG_LEVEL=info"
# 把多项配置放到单独文件，路径必须是绝对路径
EnvironmentFile=/etc/order-api/env

systemd 会把 order-api.service.d/override.conf 作为 drop-in 合并到原 unit。这个位置比直接修改发行版提供的 unit 更容易维护，升级软件包时也不需要重新合并本地改动。

Environment= 和 EnvironmentFile= 怎么选

Environment= 适合开关、模式和日志级别等少量值。若值中含空格，要把完整的 KEY=value 放在引号里；同一个变量出现多次时，后面的设置覆盖前面的设置。

EnvironmentFile= 适合配置较多的服务。文件是一行一个赋值，空行以及以 # 或 ; 开头的行可作为注释：

# /etc/order-api/env：仅保存订单服务需要的非敏感配置
APP_MODE=staging
LOG_LEVEL=info
UPSTREAM_TIMEOUT=3s

该文件路径必须是绝对路径。默认情况下，文件不存在、不可读或内容无效都会让服务启动失败；确实允许缺失时才使用 EnvironmentFile=-/etc/order-api/env。不要把数据库密码、私钥或访问令牌当作普通环境变量传递，systemd 文档明确提醒它们可能通过 D-Bus 和进程树暴露；敏感数据应考虑 credential 机制。

重载、重启并确认变量真的进入进程

如果是手工编辑文件，先让 manager 重新读取 drop-in，再重启服务。只执行 daemon-reload 不会重启已经存在的进程，因此旧进程可能仍然看不到新值。

还可以通过主进程的 /proc 环境确认运行时结果：

排查时优先看 systemctl status order-api.service 的启动错误。如果 env 文件写错，日志通常会指向读取或解析阶段；如果配置存在但进程没有更新，先确认是否只 reload 没有 restart，再确认目标服务是否实际由这个 unit 启动。

几个容易把范围做大的坑

如果 drop-in 中要清空之前的环境列表，可以单独写一行 Environment=；如果要删除某个变量，则使用 UnsetEnvironment=NAME。它会在最终环境交给进程前执行，但不会改变 ExecStart= 命令行已经完成的变量展开。

常见问题

为什么改完 EnvironmentFile 后服务仍使用旧值？

环境是在启动进程时组装的。修改文件后至少要重启目标服务；只 reload manager 不会刷新已经运行的进程环境。

EnvironmentFile 能不能写相对路径？

不能依赖相对路径，按 unit 配置使用绝对路径，例如 /etc/order-api/env，并检查 systemd 运行用户是否有读取权限。

怎样确认变量没有影响其他服务？

分别查看目标服务和另一个服务的 systemctl show 或进程环境。不要用当前 shell 的 echo $APP_MODE 代替服务进程检查。

参考资料：systemd.exec、systemctl、systemd.unit。