systemctl enable是设置开机自启的唯一可靠方式；需先确认服务单元文件存在，再执行enable创建软链接，配合--now可同时启用并启动，但必须验证is-enabled和is-active状态及journalctl日志。
systemctl enable 是当前唯一可靠的方式，其他方法要么被弃用，要么在新系统上默认不生效。
确认服务已安装且单元文件存在
执行 systemctl list-unit-files --type=service | grep 服务名，如果没输出，说明 systemd 根本没识别到该服务。常见原因包括：
-
/usr/lib/systemd/system/服务名.service或/etc/systemd/system/服务名.service文件不存在 - 服务名拼写错误（比如
nginx写成ngnix） - 服务是手动编译安装的，未附带 .service 文件
若确认无单元文件，不能跳过这步直接 enable——命令会报错 Failed to enable unit: Unit 服务名.service does not exist。
启用自启并立即启动（--now 的真实作用）
systemctl enable 服务名 --now 不是“一键搞定”，它实际分两步：enable 注册开机时机 + start 触发当前运行。但这两步不等价：
-
enable只创建软链接（如/etc/systemd/system/multi-user.target.wants/服务名.service），不检查脚本能否真跑起来 -
start才真正加载配置、校验ExecStart路径、应用User和Environment设置 - 如果
start失败（比如权限不足、路径不存在），--now会卡住并报错，此时enable已生效但服务起不来
建议拆开验证：先 sudo systemctl daemon-reload（尤其改过 .service 文件后），再 sudo systemctl start 服务名 看是否 active，成功后再 enable。
自定义脚本必须写 .service 文件，别碰 /etc/rc.local
在 Ubuntu 22.04+、CentOS 8+、Debian 11+ 上，/etc/rc.local 默认不激活，且即使启用也极易失败：
- 执行环境极简：
$PATH不含/usr/local/bin，~展开失败，systemd网络可能未就绪 - 脚本卡住（如等待用户输入、阻塞式调用）会导致整个系统启动挂起在 “A start job is running for /etc/rc.local Compatibility”
-
rc-local.service单元本身在很多发行版中已被标记为 deprecated
正确做法是新建 /etc/systemd/system/myapp.service，至少包含：
[Unit] Description=My App After=network.target [Service] Type=simple User=www-data ExecStart=/usr/local/bin/myapp.sh Restart=on-failure RestartSec=3 [Install] WantedBy=multi-user.target
注意：ExecStart 必须是绝对路径；Type=simple 表示进程前台运行，别加 &；RestartSec=3 防止崩溃后高频重启压垮系统。
验证是否真生效，不是只看 enable 成功提示
Created symlink ... 只代表软链接建成了，不代表服务能跑。必须组合验证：
-
systemctl is-enabled 服务名→ 返回enabled才算注册成功 -
systemctl is-active 服务名→ 返回active表示当前正在运行 -
sudo journalctl -u 服务名 -n 20 --no-pager→ 扫描最近日志，重点看Failed to start、Permission denied、No such file or directory
最容易被忽略的是依赖项缺失：比如脚本依赖网络，但没写 After=network.target，系统可能在网络还没 up 时就尝试启动，导致超时失败——这种问题只有看 journalctl 日志才能暴露。
