systemctl enable 是当前唯一推荐的现代服务启用方式，它通过创建软链接将服务注册到 systemd 启动目标，并需配合 daemon-reload、is-enabled 等命令验证配置与运行状态。
systemctl enable 是唯一推荐的现代做法
现在几乎所有主流发行版（Ubuntu 20.04+、CentOS 7+、Debian 10+）都用 systemd 管理启动，systemctl enable 就是标准答案——它不是“一种方法”，而是当前事实上的唯一合理路径。
其他方式要么被弃用（如 /etc/init.d 在 systemd 下只是兼容层），要么有硬伤（/etc/rc.local 在 Ubuntu 22.04+ 默认不启用，且命令卡住会导致系统卡在启动界面）。
-
systemctl enable nginx会在/etc/systemd/system/multi-user.target.wants/下建软链接，告诉 systemd：这个服务属于“多用户文本模式”的启动目标 - 加
--now（如sudo systemctl enable nginx --now）= 启用 + 立即启动，省一次start手动操作 - 禁用只需
sudo systemctl disable nginx，不会影响当前运行状态，也不会删掉.service文件
自定义脚本必须写 .service 文件，不能只丢进 rc.local
很多人图省事，在 /etc/rc.local 里直接写 /opt/myapp/start.sh，结果重启后发现没跑——不是脚本错了，是 rc.local 本身在多数新系统里压根没激活，或者执行环境缺失（没加载用户 profile、PATH 不对、没有网络就执行了）。
正确做法是把脚本包装成 systemd 服务，哪怕只有一行启动命令：
- 新建
/etc/systemd/system/myapp.service，内容至少包含[Unit]、[Service]、[Install]三段 -
ExecStart=必须用绝对路径，~或./会失败 - 加
User=指定非 root 用户（比如User=www-data），避免权限过大或家目录不可达 - 加
Restart=on-failure和RestartSec=3，防止程序崩溃后静默退出
写完务必运行 sudo systemctl daemon-reload，否则 enable 会报 “no such file or directory”。
验证是否生效，别只看 enable 成功了没
systemctl enable 命令成功返回，不代表服务真能开机跑起来。常见假成功场景：服务文件语法错、路径不存在、权限不够、依赖没满足（比如要等网络但没写 After=network.target）。
- 查启用状态：
systemctl is-enabled myapp→ 返回enabled才算注册成功 - 查当前运行状态：
systemctl is-active myapp→active表示正在跑；inactive可能根本没启，也可能启了又崩了 - 看真实日志：
sudo journalctl -u myapp -n 30 --no-pager，重点扫Failed to start或Permission denied - 模拟开机行为：
sudo systemctl daemon-reload && sudo systemctl start myapp，比 reboot 更快暴露问题
@reboot crontab 只适合轻量、无依赖的用户级命令
@reboot 看起来最简单，但它本质是 cron 的一个触发时机，不是系统服务管理机制。它跑在用户 session 里，没有 systemd 的依赖控制、资源隔离、重启策略。
- 适用场景：普通用户想开机自动挂载某目录、启动个
ssh -D代理、发个通知，且不关心它崩了要不要拉起 - 不适用场景：需要访问系统级端口（如 80）、依赖数据库或网络服务、要求稳定长期运行的后台程序
- 注意：cron 的环境变量极简（
$PATH往往只有/usr/bin:/bin），python3可能找不到，建议全路径调用，比如/usr/bin/python3 /home/user/app.py
真正要当服务用，绕不开 .service 文件——这不是多此一举，是让系统知道“你这个东西该怎么管”。
