现代linux必须用systemctl enable配合正确.service文件；自定义服务须放/etc/systemd/system/，命名如myapp.service，权限644，编辑后必执行daemon-reload。
直接说结论：现代 Linux（Ubuntu 20.04+、CentOS 7+、Debian 10+）必须用 systemctl enable 配合正确的 .service 文件，其他方法（rc.local、@reboot）要么不可靠，要么环境缺失严重，不建议用于生产服务。
service 文件该放哪、怎么命名、权限多少
自定义服务文件必须放在 /etc/systemd/system/，不能丢进 /lib/systemd/system/ 或自己建子目录——systemd 不扫描子目录，/lib 是软件包管理器专用路径，改了会被覆盖。
文件名必须以 .service 结尾，例如 myapp.service；权限设为 644（sudo chmod 644 /etc/systemd/system/myapp.service）；编辑完必须立刻执行 sudo systemctl daemon-reload，否则 enable 会静默失败，什么提示都没有。
ExecStart 写错的三种典型表现
ExecStart 是唯一必需字段，但它不是 shell 命令行，不能直接写 python app.py | grep ok 这类带管道或重定向的语句。写错后最常见现象是服务卡在 activating (start) 状态，或者秒退报 failed with result 'exit-code'。
-
ExecStart=python app.py会失败，必须写成绝对路径：ExecStart=/usr/bin/python3 /opt/myapp/app.py - 脚本依赖 virtualenv？得显式声明环境变量：
Environment="PATH=/opt/myapp/venv/bin:/usr/local/bin:/usr/bin:/bin" - 脚本启动后立即返回（比如内部调用了
nohup & exit），systemd 会认为进程已退出，服务结束；正确做法是让主进程前台运行，或设置Type=simple并确保它不自行 daemonize
为什么 start 没问题但 reboot 后不启动
根本原因：只写了 .service 文件 ≠ 开机自启。systemd 严格区分「服务存在」和「服务启用」两个状态。没 enable，就只是个躺在磁盘上的配置文件。
启用命令是 sudo systemctl enable myapp.service，它会在 /etc/systemd/system/multi-user.target.wants/ 下创建软链接；验证是否真正启用，运行 systemctl is-enabled myapp.service，返回 enabled 才算到位。
注意 WantedBy=graphical.target 在无桌面的服务器上不会生效，后台服务统一用 WantedBy=multi-user.target；如果服务依赖网络，[Unit] 段里必须加 After=network.target 和 Wants=network.target，否则可能因网卡未就绪而启动失败。
调试自启动失败最有效的三步
别猜，直接看日志。systemd 的所有启动过程都记在 journal 里，/var/log/syslog 通常不完整。
查最后一次启动详情：sudo journalctl -u myapp.service -n 50 --no-pager（-n 50 只看最近 50 行，避免刷屏）
如果服务刚启用还没重启过，先手动触发一次：sudo systemctl start myapp.service，再立刻查日志；若仍失败，用 sudo systemd-analyze verify /etc/systemd/system/myapp.service 检查语法错误——这个命令不报错，才代表单元文件本身是合法的。
