四个动作的语义
start、stop、restart、reload 看着都是「让服务变一下」，但语义差别很大：start 是幂等的，服务已在运行时什么都不做；stop 停止当前实例；restart 是先停止再启动，中间必然有中断窗口，未完成的请求与内存态都会丢失；reload 让进程重新读取配置而不重启，已有连接通常保留。生产变更时选哪个动词，取决于这次改动能否承受中断，而不是命令是否写起来顺手。
基本信息
| 适用平台 | Linux（systemd 发行版） |
|---|---|
| 命令语法 | systemctl start|stop|restart|reload [--no-block] 单元 |
| 相关动作 | try-restart 仅在运行中才重启、reload-or-restart 先尝试重载失败则重启、kill 发信号、is-active 查询状态 |
| reload 的前置条件 | 单元必须定义 ExecReload（或应用自身支持约定的信号），否则会报 Job type reload is not applicable |
| 权限要求 | 需要 root 或 sudo；用户级单元用 systemctl --user |
典型使用场景
- 改配置后用 reload：Nginx、sshd 这类支持平滑重载的服务，避免中断现有连接
- 发布新版本用 restart：二进制变更必须重启才能生效
- 计划内维护用 stop：先停流量再操作数据或迁移
- 脚本里做条件判断：用 is-active 判断后再决定动作，避免对未运行的服务做无意义重启
- 批量操作多台机器：用 try-restart 只影响正在运行的服务，避免把本该停止的服务意外拉起
- 变更中留退路：reload-or-restart 让支持平滑重载的服务优先走低中断路径
常用示例
常用示例
systemctl reload nginx # 平滑重载（不断开现有连接）
systemctl restart myapp # 重新拉起（有中断窗口）
systemctl stop myapp # 停止
systemctl is-active nginx && systemctl reload nginx # 先确认在跑
systemctl try-restart myapp # 只有在运行时才重启
systemctl reload-or-restart myapp # 能重载就重载，否则重启
systemctl reload myapp || systemctl restart myapp # 显式的回退写法
systemctl --no-block restart myapp # 不等待作业完成，适合脚本批量
systemctl show -p ActiveState -p SubState -p ExecMainPID myapp动作对照
| 动作 | 语义 | 中断与影响 |
|---|---|---|
| start | 拉起服务，已运行则不做任何事 | 无中断，天然的幂等 |
| stop | 停止当前实例 | 有中断，停止期间上游流量会直接打空 |
| restart | 停止后重新启动 | 有中断，内存态与未完成请求丢失 |
| reload | 重读配置不重启进程 | 通常无中断，需要单元定义 ExecReload |
| try-restart | 仅在运行中才重启 | 不会把已停止的服务拉起来 |
| reload-or-restart | 优先重载，失败则重启 | 兼顾低中断与最终生效 |
reload 能否真正生效取决于应用：Nginx、sshd、多数 Web 服务支持平滑重载，但并非所有程序都实现了重读配置的逻辑。改完配置后用 systemctl show -p ExecReload 单元 确认该字段存在，reload 之后再到日志或状态里确认新配置已加载，而不是默认它生效了。
restart 对数据库、消息队列这类有状态服务意味着连接中断、缓冲丢弃，甚至触发长时间恢复或主从切换。这类服务的变更应优先使用应用自己的在线参数调整、滚动重启或主备切换方案，并安排在业务低峰执行。
变更脚本里 stop 与 start 必须成对出现并带错误处理：中途失败时服务会停留在停止状态，直到有人发现流量全空。更稳的写法是用 restart 或 reload-or-restart 这类单命令完成切换，结束后用 is-active 验证结果并输出到日志。批量变更时先用 is-active 过滤出正在运行的实例，避免把本就该停止的服务一起拉起来。
对不中断处理请求的服务优先用重载而不是重启：重载只让进程重新读取配置，连接与内存状态不丢。数据库与消息中间件这类有状态组件还要考虑主从切换与恢复耗时，变更窗口要单独评估，不能按无状态服务的节奏安排。