最准的判断方式是查看 /etc/rc.d/rc3.d/（或对应运行级目录）中以 s 开头的软链接的数字序号，数字越小越先执行，如 s01sysstat 在 s99local 之前运行。
直接看 /etc/rc.d/rc3.d/（或对应运行级目录）里的软链接顺序，是最准、最不绕弯的判断方式。 systemd 系统里用 systemctl list-dependencies 只能看依赖关系，不是实际执行顺序；systemd-analyze blame 显示的是耗时，不是启动次序。真要确认“哪个脚本先跑、哪个后跑”，必须回到 SysVinit 风格的命名规则上——哪怕你用的是 CentOS 7 或 RHEL 7 这类 hybrid 系统，/etc/rc.d/rc.local 和 /etc/rc.d/rc.sysinit 的位置与作用依然生效。
怎么看 /etc/rc.d/rcN.d/ 下的真实执行顺序
系统启动时，/etc/rc.d/rc 脚本会按数字升序依次调用 /etc/rc.d/rcN.d/（如 rc3.d）中以 S 开头的软链接所指向的 /etc/init.d/ 脚本。
-
S01sysstat比S99local先执行，因为 01 -
K开头的只在关机/切换运行级时执行，开机时忽略 - 软链接目标必须存在且可执行，否则启动会报错但通常不中断流程
- 运行级由
/etc/inittab中id:3:initdefault:决定；若无该文件（如较新 systemd 系统），默认取multi-user.target对应的运行级（通常是 3）
systemd 系统下怎么查服务的实际启动次序
虽然 systemd 不再靠数字排序，但服务单元（.service）的加载和激活顺序仍受 WantedBy=、After=、Before= 等字段控制。想看到真实加载链：
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 用
systemctl list-dependencies --all multi-user.target查整个目标树，注意层级缩进反映加载先后 - 对单个服务，如
nginx，运行systemctl show nginx.service | grep -E "After=|Before=|Wants=|WantedBy="，重点关注After=列出的服务名 -
systemctl cat nginx.service能看到原始单元文件内容，其中After=network.target表示它必须在网络服务之后启动 - 别信
systemctl list-unit-files --type=service的列表顺序——那是按字母排的，跟启动无关
/etc/rc.local 是最后一个执行的系统级脚本，但有坑
在 RHEL/CentOS 7 及更早版本中，/etc/rc.d/rc.local（等价于 /etc/rc.local）确实在所有 rcN.d 脚本之后、登录前执行。但它不是“万能补丁”：
- 必须有可执行权限：
chmod +x /etc/rc.d/rc.local，否则 systemd 会跳过它 - systemd 下需确保
rc-local.service已启用：systemctl enable rc-local.service - 脚本里不能依赖未就绪的服务（比如直接
curl http://localhost可能失败），建议加sleep或用systemctl is-active --quiet service-name做等待 - CentOS 7.9 默认禁用
rc-local，即使文件存在也不会运行，必须手动启用服务单元
真正容易被忽略的是：同一运行级下，/etc/rc.d/rc.sysinit 是第一个执行的初始化脚本，而它本身不接受外部干预；所有自定义逻辑如果必须早于网络、磁盘挂载等基础服务，只能改它——但风险极高，一般不推荐。绝大多数场景下，把动作塞进 /etc/rc.d/rc.local 或写成 proper systemd unit 并设置好 After=，才是安全边界内的正确做法。
