你的服务器出了点小毛病。内存占用高，某个服务卡住了。你想着“重启一下就好了”，手指熟练地敲下reboot。
然后屏幕卡住，连接断开。你等了两分钟，重新连上去，发现MySQL没起来，因为上次关机太突然，表损坏了。你又花了半小时修复数据库。
重启这个操作，看似简单，做错了代价很大。今天聊聊5个正确的重启姿势。
先看一个数据
某云厂商统计，超过20%的“服务器故障”是由不正确的重启导致的。数据没来得及写入磁盘、数据库表损坏、配置文件没保存、服务启动顺序错乱。这些问题往往比原来的故障更麻烦。
reboot本身没错，错的是你不给它缓冲时间。
姿势一：先通知用户
如果你重启的是生产环境的服务器，用户正在使用你的网站。
他们可能正在下单、写文章、上传文件。你突然重启，他们的操作就断了。
正确做法：
- 在网站上放一个公告：“系统将于X分钟后重启维护”
- 或者把网站切换到维护模式（503状态码）
- 在团队群里同步一下重启时间
如果是半夜紧急重启，至少让同时操作的同事知道，别两个人同时重启导致文件损坏。
姿势二：优雅停止服务
直接reboot，操作系统会向所有进程发送终止信号，但进程不一定来得及清理现场。数据库可能还在写数据、缓存还没同步到磁盘。
正确做法：先手动停掉关键服务。
bash
systemctl stop nginx systemctl stop php7.4-fpm systemctl stop mysql
停服务的顺序：先停Web服务，让新请求进不来；再停PHP、数据库等后端服务。MySQL是重点，一定要等它完全退出。
验证服务已停止：
bash
systemctl status mysql
看到inactive (dead)再执行下一步。
姿势三：同步磁盘数据
Linux会把数据先写在内存里，再慢慢写入磁盘。reboot会触发同步，但有时候等不及。
正确做法：重启前手动执行同步命令。
bash
sync
这个命令强制把内存中待写入的数据刷到磁盘。可以执行两三次，确保万无一失。
姿势四：选择合适的重启方式
| 命令 | 效果 | 适用场景 |
|---|---|---|
reboot | 正常重启 | 日常使用 |
shutdown -r now | 与reboot类似，可指定时间 | 延时重启 |
systemctl reboot | 同reboot，systemd专用 | 新版Linux |
reboot -f | 强制重启，不通知进程 | 系统卡死时用 |
| 云控制台“硬重启” | 相当于拔电源 | 系统完全无响应时用 |
大部分情况用reboot或shutdown -r now就够了。只有系统完全卡死、SSH连不上时，才用reboot -f或去云控制台硬重启。
姿势五：重启后检查服务
服务器起来了，不等于服务都起来了。
有些服务依赖网络、依赖其他服务，启动顺序错乱可能导致没起来。
重启后检查清单：
bash
# 查看所有关键服务状态 systemctl status nginx systemctl status php7.4-fpm systemctl status mysql # 检查端口是否在监听 netstat -tunlp | grep :80 netstat -tunlp | grep :3306 # 查看最近的系统日志 journalctl -xe -n 50 # 尝试访问网站 curl -I http://你的域名
如果发现有服务没起来，手动启动：
bash
systemctl start 服务名
确认一切正常后，再关掉维护模式，让用户进来。
真实案例：一个代价2000元的reboot
一个朋友的数据库服务器，内存泄漏，他直接reboot。重启后MySQL起不来，报错InnoDB: corruption。数据恢复花了2000元找专业公司，还丢了当天的订单。
后来复盘：如果重启前先停MySQL、执行sync，大概率不会坏。即便坏了，有备份也能自己恢复。
他说：“一个reboot按下去，2000块没了。”
什么时候不该重启？
重启不是万能药。有些情况重启解决不了问题，甚至会雪上加霜：
- 磁盘满了：重启后MySQL可能起不来，因为写不了日志
- 硬件故障：风扇坏了、内存坏了，重启也修不好
- 被攻击：攻击脚本可能写在开机启动项里，重启后还会跑起来
遇到这些情况，先排查，再决定是否重启。
最后一句话
重启不是点一下鼠标的事。它是你对服务器做的最后一个操作，意味着之前的所有状态都将消失。
通知用户、停服务、同步磁盘、选对命令、检查状态。5步走完，服务器才能健康重启。
下次你敲reboot之前，先停一秒。想一下这5件事做了没。
你的数据会感谢你。