最准的方法是运行 systemctl list-unit-files --type=service --state=enabled，它直接读取 systemd 单元文件的启用标记，不依赖当前运行状态或服务依赖关系，能准确反映系统承诺开机拉起的服务列表。
最准的方法是运行 systemctl list-unit-files --type=service --state=enabled，它直接读取 systemd 单元文件的启用标记，不依赖当前是否运行、也不受其他服务拉起影响。别用 systemctl list-units 替代——它只显示已加载的服务，会漏掉那些“开机启用但还没启动”的项（比如 logrotate.service 或 certbot.timer）。
查所有真正开机自启的服务
执行 systemctl list-unit-files --type=service --state=enabled 是唯一能反映系统“承诺开机时拉起哪些服务”的命令。它的输出来自单元注册表，不是运行时快照。
- 带
@符号的（如getty@.service）是模板，实际启用的是getty@tty1.service这类具体实例，--state=enabled会列出后者 -
static状态的服务（如systemd-journald.service）不会出现在结果里，它们由其他单元隐式触发，不能手动disable -
masked表示被硬屏蔽（符号链接指向/dev/null），disabled表示明确关闭，这两类都不参与开机启动
查单个服务是否真被设为开机自启
用 systemctl is-enabled servicename.service，返回值只有 enabled、disabled、masked 或 generated 四种，无歧义。
- 别只看
systemctl status servicename的 “Loaded” 行末尾写的enabled; vendor preset: enabled——vendor preset 可能被本地配置覆盖，is-enabled才是最终生效状态 - 服务名必须带
.service后缀，否则部分系统会报错或返回意外结果（例如查dbus-broker时可能误匹配到dbus.service） - 桌面环境里的用户级服务（如
gnome-keyring.service）要用systemctl --user is-enabled查，系统级命令查不到
为什么 systemctl enable 之后服务还是不自启？
常见原因不是命令没跑，而是几个关键环节断在了前面：
- 服务单元文件根本不存在：
systemctl list-unit-files --type=service | grep yoursvc无输出 → 需先创建/etc/systemd/system/yoursvc.service - 单元文件语法错误：运行
sudo systemd-analyze verify /etc/systemd/system/yoursvc.service，报错就修，否则enable成功但启动失败 -
ExecStart=路径写错或权限不足：必须是绝对路径，且User=指定的用户有执行权限；建议先手动试一遍：sudo -u youruser /path/to/binary --help - 依赖未满足：比如服务依赖网络，但只写了
After=network.target却没加Wants=network.target，导致启动时跳过 - 改完单元文件后忘了
systemctl daemon-reload，systemd 不会自动感知变化
注意：/etc/rc.d/ 和 chkconfig --list 在 Ubuntu 22.04+、CentOS 8+、Debian 11+ 上基本失效，它们要么不存在，要么只是兼容层残留；图形界面的用户级自启项（如 ~/.config/autostart/ 下的 .desktop 文件）也不归 systemd 系统服务管理范畴。
