systemd 是当前最可靠、最推荐的开机自启方案，尤其适用于 CentOS 7+、Ubuntu 16.04+ 等主流发行版；rc.local 需手动启用且环境简陋，/etc/profile.d/ 仅对交互式 shell 生效，根本不是开机自启机制。
systemd 服务方式是当前最可靠、最推荐的方案，尤其在 CentOS 7+、Ubuntu 16.04+ 等主流发行版上；rc.local 方式看似简单，但默认可能被禁用或执行失败；/etc/profile.d/ 下的脚本只对交互式 shell 生效，根本不会在开机时运行——它不是开机自启机制。
用 systemd 创建 .service 文件（推荐）
这是现代 Linux 的标准做法，能精确控制启动时机、用户身份、依赖关系和重启策略。关键点在于 After= 和 User= 的设置必须匹配实际需求。
- 脚本必须有可执行权限：
chmod +x /opt/myscript.sh - 服务文件放在
/etc/systemd/system/myscript.service，内容中ExecStart=必须写绝对路径 - 若脚本依赖网络，
After=network.target是基本要求；若需 DNS 解析，得加After=network-online.target并启用systemctl enable systemd-networkd-wait-online.service - 启动后日志用
journalctl -u myscript.service -f查看，比写文件更可靠 - 启用并立即测试：
systemctl daemon-reload && systemctl enable myscript.service && systemctl start myscript.service
通过 /etc/rc.local 添加命令（兼容但需手动激活）
这个方法在旧系统上有效，但在多数 systemd 发行版中，rc-local.service 默认不启用，且脚本执行环境极简（PATH 很短、无用户会话变量）。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 编辑
/etc/rc.local，把命令加在exit 0之前，例如：/opt/myscript.sh > /var/log/myscript.log 2>&1 - 必须确保文件可执行：
chmod +x /etc/rc.local - 必须启用对应 service：
systemctl enable rc-local（否则什么都不会发生） - 常见失败原因：脚本里用了
sudo、systemctl、su - user -c等交互命令，或依赖未就绪的网络服务 - 如果脚本要以非 root 用户运行，建议改用 systemd 的
User=字段，而不是在 rc.local 里硬套su
误用 /etc/profile.d/ 的后果
很多教程说“把脚本放 /etc/profile.d/ 就能开机自启”，这是严重误导。/etc/profile.d/ 下的脚本只在用户登录 Shell 时 sourced（即加载为环境的一部分），根本不会在系统启动阶段执行。
- 它不适用于无人值守服务器、后台服务、定时任务等场景
- 即使 root 登录了，也只影响该次 Shell 会话，关掉终端就失效
- 如果你看到它“好像生效了”，大概率是误将脚本逻辑写进了 profile 或 bashrc，并在某个登录环节被触发，属于巧合而非机制
- 真正需要用户登录后才运行的东西（比如 GUI 启动项），应该走桌面环境的 autostart 目录，而不是 profile.d
最容易被忽略的是环境差异：systemd 服务默认没有 $HOME、没有 $DISPLAY、PATH 极其有限；而 rc.local 几乎没有 shell 初始化过程。任何依赖这些的脚本，不显式设置就会静默失败。调试前先确认日志输出是否真被写入，别只看进程是否存在。
