VPS上手动执行程序一切正常，改成 systemd 服务后却提示缺少 PATH、配置文件、数据库地址或 Token，通常不是程序突然损坏，而是 systemd 启动的进程不会自动继承你的交互式 Shell 环境。服务可能使用不同用户、工作目录、环境文件和启动参数。排查应以“服务实际拿到什么”为准。
先比较Shell与服务的真实环境
env | sort
systemctl show <service> --property=User,WorkingDirectory,Environment,EnvironmentFiles,ExecStart
systemctl status <service> --no-pager
不要把完整环境直接发到工单，因为里面可能包含密钥和内部地址。可以只输出变量名、路径和脱敏值；服务端实际环境可在受控窗口通过进程信息确认。
用EnvironmentFile显式声明配置
对于少量非敏感配置，可在 unit 中使用 Environment=；更常见的是使用权限受限的 EnvironmentFile=。文件格式、引号和变量展开规则与 Shell 脚本不同，不能把任意 export 脚本直接当成环境文件：
[Service]
User=app
WorkingDirectory=/opt/app
EnvironmentFile=/etc/<service>/<service>.env
ExecStart=/usr/bin/<program> --config /etc/<service>/config.yml
示例中的路径和程序名为占位符。环境文件应由 root 或服务账号按最小权限拥有，避免把 Token 写入 unit 文件、命令行参数或公开日志；如果平台提供密钥管理服务，优先使用专门的凭据注入方式。
检查PATH、工作目录和用户身份
Shell里的别名、用户级 profile 和当前目录不会自动存在于 systemd。建议在 ExecStart 中使用绝对路径，明确设置 WorkingDirectory，并确认 User 对配置、证书、日志和数据目录拥有最小必要权限。相对路径导致的“找不到文件”，经常被误判为环境变量问题。
修改后按正确顺序加载与重启
systemd-analyze verify /etc/systemd/system/<service>.service
sudo systemctl daemon-reload
sudo systemctl restart <service>
systemctl show <service> --property=Environment,ExecMainPID
如果只改了 EnvironmentFile，是否需要 daemon-reload 取决于文件变化位置，但重启服务才能让新环境进入进程。不要在高峰期直接重启核心业务，先用独立 unit、维护窗口或灰度实例验证。
核对进程实际环境与日志
pid=$(systemctl show -p MainPID --value <service>)
tr '' '
' < /proc/$pid/environ | sed -E 's/^(TOKEN|PASSWORD|SECRET)=.*/1=[REDACTED]/'
journalctl -u <service> -b --no-pager | tail -n 100
读取 /proc/$pid/environ 需要相应权限，且只应在受控主机上执行。日志中重点看配置文件路径、用户身份、工作目录和退出码，不要让程序把完整环境打印到日志。
常见误区
- 把
~/.bashrc或 profile 当成 systemd 的默认环境。 - 在
ExecStart写相对路径，依赖当前终端目录。 - 把密钥放进命令行参数，导致可能被进程列表看到。
- 修改 unit 后忘记 daemon-reload 或重启服务。
- 让服务以 root 运行，只为绕过配置文件权限。
验收清单
- 服务实际 User、WorkingDirectory、EnvironmentFile 和 ExecStart 与设计一致。
- 用最小权限读取配置和凭据，公开日志不包含密钥。
- 重启后从独立会话验证健康检查、业务请求和错误率。
- 记录变更前后配置版本和回滚方法，确认失败时不会影响备用实例。
systemd环境问题的关键不是把Shell变量“复制过去”，而是明确服务契约：谁运行、在哪运行、拿到哪些配置、如何验证。环境显式化并做好凭据隔离，通常能同时解决启动失败和安全暴露。
