想要准确查看 Linux 开机自启的服务列表，最可靠的方法就是直接执行 systemctl list-unit-files --type=service --state=enabled。这条命令之所以最值得参考，是因为它直接读取 systemd 单元文件的启用标记，能够绕过当前运行状态以及服务依赖关系带来的干扰，更真实地反映系统在启动时会自动拉起的服务清单。
systemctl list-unit-files --type=service 是查看开机启动服务的最准依据
它会直接读取 systemd 单元文件中的 WantedBy= 或 RequiredBy= 配置，不依赖服务当前是否正在运行，也不会受到 SysV 兼容层的影响。只要某个服务执行过 systemctl enable，这里通常就会标记为 enabled。
很多人常犯的错误，是只查看 systemctl list-units --state=active，结果会漏掉那些已经设置为开机自启、但当前并未运行的服务，例如刚安装完成但还没有重启系统的 nginx.service。
- 只查看已启用的服务项：
systemctl list-unit-files --type=service --state=enabled - 排除意义不大的
static项（例如syslog.socket）：systemctl list-unit-files --type=service | awk '$2 == "enabled" && $1 !~ /.socket|.timer$' - 加上
--no-pager防止输出分页或被截断：systemctl list-unit-files --type=service --state=enabled --no-pager
从 /etc/systemd/system/multi-user.target.wants/ 查看实际生效的链接
说得更直白一点，这个目录中的符号链接，就是执行 systemctl enable 后留下的直接证据。它们分别指向 /usr/lib/systemd/system/xxx.service 或 /etc/systemd/system/xxx.service，可以直观说明该服务已经被正式加入 multi-user.target 的启动流程。
这里也有一个常见误区：有些人只是手动把 service 文件放到 /etc/systemd/system/ 目录下，却没有执行 enable。这种情况下，它既不会出现在这个目录中，也不会实现开机自动启动——systemd 认的是链接关系，而不是“文件放在那里就算启用”。
- 列出所有已启用服务的软链接：
ls -l /etc/systemd/system/multi-user.target.wants/ - 检查某个服务是否真的建立了链接：
ls /etc/systemd/system/multi-user.target.wants/nginx.service 2>/dev/null || echo "not linked" - 注意：部分服务可能会链接到
graphical.target.wants/，例如桌面环境相关服务
systemctl is-enabled 判断单个服务是否自启最可靠
在脚本处理或自动化排查场景中，systemctl is-enabled xxx.service 的返回值非常适合机器读取，例如：enabled、disabled、masked、static。相比用 grep 去匹配文本，这种方式更稳定，也不会受到终端宽度或 locale 环境影响。
不要用 systemctl status xxx 的输出去解析其中是否包含 “enabled” 字样——虽然它在 Loaded: 行中可能显示 enabled，但那里往往混合了 vendor preset 与当前设置，实际判断时很容易出现误判。
- 查询 nginx 是否设置开机自启：
systemctl is-enabled nginx.service - 批量检查几个关键服务：
for s in sshd chronyd firewalld; do printf "%-12s: %sn" "$s" "$(systemctl is-enabled "$s.service" 2>/dev/null)"; done masked表示服务被彻底禁用（systemctl mask），此时连手动 start 都会失败
旧系统环境中 chkconfig 和 /etc/rc.d/ 仍然需要关注
在 CentOS 7.9、RHEL 7 等仍然较常见的系统中，部分服务，尤其是第三方程序或自建脚本，可能依旧走的是 SysVinit 路径。这时候，chkconfig --list 以及 /etc/rc.d/rc3.d/ 目录下的 Sxx* 链接，才是判断其启动方式的真实入口。
不过也要特别注意：如果同名服务同时存在 systemd unit 和 SysV init script，systemd 通常会优先使用 unit；这意味着 SysV 配置有可能被忽略，所以即使 chkconfig 输出显示为 on，也不一定代表它最终一定会随系统启动。
- 查看传统服务的启用状态：
chkconfig --list | awk '$2~/^on$/ {print $1}' - 查看 runlevel 3 的启动脚本：
ls /etc/rc.d/rc3.d/S* - 确认某个服务是否已经由 systemd 托管：
systemctl list-unit-files | grep "^$svc.service"，如果有结果，就不要只参考chkconfig
真正麻烦的地方，不是命令本身难记，而是在 systemd 和 SysV 混用的 Linux 系统里，同一个服务可能同时存在两套启动逻辑。最终只有 systemctl list-unit-files 以及对应的 .wants/ 目录，才能更准确反映实际生效的开机启动路径。
