systemd 服务启动行为由 Type、WantedBy、After、Requires 等字段共同决定，而非仅 ExecStart；cgroup v2 下需防 scope 绕过限制；EnvironmentFile 中变量不展开 shell 语法，须用 %h 等替换符。
Linux 服务运行环境不是“配好就完事”的静态状态，而是由 systemd 动态调度、受资源限制约束、依赖明确启动顺序的运行时上下文。直接改 配置文件 不 reload 或忽略 cgroup 边界，服务大概率会启动失败或行为异常。
systemd 服务单元文件里哪些字段真正影响启动行为
很多人以为 ExecStart 是唯一关键项，其实 Type、WantedBy、After 和 Requires 才决定服务能否在目标时机正确拉起。
-
Type=simple（默认）：systemd在 fork 出主进程后即认为启动成功，适合前台常驻进程；若程序自行 daemonize（如加-d参数），应改用Type=forking并配好PIDFile= -
After=network.target只表示“在网络 target 启动之后”，不保证网络已通；需真正依赖网络连通，应加Wants=network-online.target+After=network-online.target -
Requires=redis.service表示强依赖：若 redis 启动失败，当前服务不会尝试启动；而Wants=是弱依赖，只触发并行启动，不阻断 -
Restart=on-failure默认只对非 0 退出码重启，若程序靠 signal 退出（如kill -TERM），需显式加RestartPreventExitStatus=143避免误重启
内存与 CPU 限制不生效？检查 cgroup v2 和 scope 冲突
在较新内核（5.8+）且启用 cgroup v2 的系统上，MemoryLimit、CPUQuota 等资源限制可能被忽略——因为服务被自动放进 scope 而非 service 单元，导致限制未继承。
- 确认是否启用 cgroup v2：
cat /proc/cmdline | grep cgroup，含
cgroup_no_v1=all或无cgroup_enable=即为 v2 模式 - 查看服务实际所在 cgroup：
systemctl status your-service | grep "CGroup:"，若路径含
scope（如/sys/fs/cgroup/system.slice/your-service.scope/），说明它被临时 scope 包裹，绕过了 unit 级限制 - 强制回归 service 模式：在 unit 文件中加
Scope=false（仅适用于非 transient 服务），或避免用systemd-run --scope启动 - v2 下
MemoryLimit=512M有效，但MemoryLimit=512MB会解析失败（单位必须是K、M、G，不能带B）
环境变量 加载顺序混乱导致配置读取错误
EnvironmentFile 和 Environment 不是覆盖关系，而是按声明顺序逐个注入，后声明的同名变量会覆盖前面的——但 shell 脚本式变量展开（如 $HOME）在 unit 解析阶段不执行，必须用 %h 这类 systemd 替换符。
-
EnvironmentFile=/etc/default/myapp中写LOG_DIR=$HOME/logs→$HOME不会被展开，最终变成字面量字符串 - 正确写法：
Environment=LOG_DIR=%h/logs（%h展开为用户 home 目录），或在EnvironmentFile中用绝对路径：LOG_DIR=/var/log/myapp - 若需动态生成环境变量（如从命令输出获取 token），不能用
Environment=API_KEY=$(curl ……)；应改用ExecStartPre=/path/to/fetch-key.sh把值写入文件，再用EnvironmentFile加载 - 注意
sudo systemctl start启动的服务默认以 root 运行，%h展开为/root，而非你本地用户的 home
真正难的不是写对某一行配置，而是理解 systemd 如何把 unit 定义、cgroup 层级、环境变量 作用域 和依赖图谱编织成一个可预测的运行环境——漏掉任意一环，服务都可能在凌晨三点安静地停止响应，而日志里只有一行“exited with code 0”。
