WorkingDirectory 指定服务进程启动时的工作目录，决定相对路径解析、模块加载基准、日志/临时文件生成位置及安全沙盒范围；必须为存在的绝对路径，运行用户需有rx权限，支持%h %u等变量扩展。
WorkingDirectory 的核心作用
它指定了服务进程启动时的当前工作目录（即 shell 中的 cd 目标路径），直接影响：
- 所有相对路径的解析起点（如
./config.yaml、logs/app.log） - Node.js 的
require()或 Python 的import查找路径基准 - 服务默认生成临时文件、日志、PID 文件的位置（除非命令中显式指定绝对路径）
- 配合
ProtectSystem=strict等安全选项，限制服务对文件系统的实际访问范围
必须遵守的配置规则
这条指令看似只写一行路径，但有四个硬性要求，缺一不可：
-
必须是绝对路径：不能用
~、./或../；例如/opt/myapp✅，~/myapp❌ -
目录必须预先存在：systemd 启动时不会自动创建该目录，不存在则服务直接失败（
failed with result 'start-limit-hit'） -
运行用户必须有读+执行权限（rx）：否则报
Permission denied；若需写入，还需w权限 -
支持有限变量扩展：如
%h（用户家目录）、%u（用户名），但仅在路径中有效，且变量展开后仍须满足上述三条
典型配置写法与常见错误
正确示例：
[Service] User=webapp WorkingDirectory=/var/www/myproject ExecStart=/usr/bin/npm start
此时 npm start 会在 /var/www/myproject 下执行，能正常读取 package.json 和 .env。
错误写法举例：
-
WorkingDirectory=../myapp—— 相对路径，systemd 拒绝加载 -
WorkingDirectory=/srv/app但该目录未创建或属主不是webapp—— 启动卡在activating (auto-restart) -
WorkingDirectory=/home/%u/app用于系统级服务（User=root）——%u展开为root，但/home/root可能无执行权限或不符合最小权限原则
验证和调试方法
配置完成后，别急着启用，先做三步检查：
- 手动模拟：用服务用户身份执行
sudo -u webapp ls -ld /var/www/myproject，确认目录存在且可进入 - 加载并检查语法：
sudo systemctl daemon-reload && sudo systemctl cat myapp.service | grep WorkingDirectory - 启动后查实际工作目录：
sudo systemctl status myapp.service看是否报错；再查进程：sudo cat /proc/$(pidof node)/cwd（替换为你的主进程名），输出应为配置的绝对路径
