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 文件——这不是多此一举，是让系统知道“你这个东西该怎么管”。