Linux系统重置root（破解密码）

半夜十二点，手机响了。

"哥，服务器密码忘了，现在连不上，明天早上领导要看演示……"

这种场景我相信不少运维朋友都遇到过。接到求助电话的第一反应不是生气，而是先确认一个核心问题：你能碰到物理机器吗？ 如果对方说机器在机房，自己只有SSH，那这事就复杂了；如果对方能走到控制台前，或者那是台VMware/KVM虚机，好办，直接进单用户模式重置密码，五分钟搞定。

这篇文章围绕的就是这个操作，我把它从原理到实操从头到尾捋一遍。很多教程只会告诉你"按e加参数"，但不会告诉你为什么换了个发行版就不好使，也不会告诉你重置完密码后SELinux会给你挖个多大的坑。这些坑我都踩过，写出来给大家当参考。

先给一个负责任的定性：这篇文章讨论的是合法管理场景下的密码恢复操作，适用于你自己的服务器、你管理的设备，或者拿到授权后进行的维护工作。所谓"破解"，本质是绕过登录认证进入系统内部修改密码文件，而不是冲击系统安全边界。如果你面对的是一台有硬盘加密、有BIOS密码、有安全启动强校验的机器，那不是这篇文章能解决的，那需要的是硬件级授权和正规数据恢复流程。

1. 重置root密码的前置门槛：先搞清什么情况下这条路走得通

很多人一上来就在网上搜"Linux破解密码"，搜出来一堆教程，跟着操作却发现怎么都不行。原因多半是没搞清楚前提条件。重置root密码在技术上确实可行，但前提非常明确，而且每一个条件都会直接影响你能不能走通这条路。

1.1 第一道门槛：物理接触权限

这里的"物理接触"是一个广义概念。服务器在机房机柜里，你有IPMI/iLO/iDRAC远程控制卡，能挂载虚拟光驱、能打开远程控制台，这算物理接触；虚拟机在VMware/KVM/Proxmox上，你能打开VNC或Web控制台，这同样算物理接触；笔记本就在你面前，那更是直接接触。

为什么这条这么重要？因为重置root密码的整个流程绕不开重启机器，并且需要在开机过程中打断正常引导流程。纯远程SSH连接，无论你拿到的账号是什么权限，都无法在已运行的系统上直接重置root密码——除非你本来就有root权限，那直接用passwd不就行了？所以，没有物理控制权限，这条路就走不通。

我之前接过一个案例，对方是云服务器，密码忘了，来问我怎么重置。我直接说：云服务器不用这么折腾，去云控制台找"重置密码"或"重置实例密码"功能，云端平台本身有底层权限，可以直接帮你改掉。所以大家在动手之前先冷静判断一下：这台设备是什么？物理机、虚拟机、云主机？不同场景有完全不同的处置路径。

1.2 第二道门槛：启动链路不能被硬性阻断

现在很多系统的安全等级比几年前高不少，有几种情况会直接卡死重置流程：

• 全盘加密：LUKS/dm-crypt、BitLocker整盘加密，开机时在GRUB之前就会让你输入解密密码。如果你连这个密码都没有，那所有单用户模式、rd.break方案都是白搭——系统根本加载不到你要修改的文件系统。这种场景下唯一的路子是找当初的加密密钥恢复材料，或者走正规的数据销毁/重建流程。
• 固件级密码（BIOS/UEFI Password）：如果机器设置了BIOS密码，开机直接拦截你的启动介质选择，GRUB界面都到不了，同样没法操作。
• Secure Boot极端强制校验：这个不用太担心，主流的Ubuntu、CentOS/RHEL等发行版的签名内核都兼容Secure Boot，但如果你装的是深度修改过的自编译内核，Secure Boot开启状态下注入参数可能引导失败，需要先关闭或进入固件调整。

1.3 第三道门槛：root密码本身与"策略合规"的关系

这里要摆正一个观念。重置root密码不是"破解"，而是在你有合法管理权限的前提下，通过修改内核启动参数绕开登录认证，进入系统内部重新设置密码。它绕过的不是安全边界（比如加密层、TPM校验），而是登录认证这一步。就像你有家门钥匙但是门锁卡住了，请开锁师傅来把锁芯换掉——这个操作的前提是你能证明这是你家的门。

所以，给所有读者一个忠告：这个技能是用来救急的，不是用来突破别人系统的。未经授权对他人设备执行密码重置，在法律上可能构成破坏计算机信息系统行为，后果很严重。我在后文的所有操作步骤，都是假设你有权对这台设备进行维护。

2. 重置前必须搞懂的启动链路：GRUB、initramfs与systemd的角色

很多教程直接告诉你"开机按e，加参数，按Ctrl-X"，但完全不解释为什么这样能生效。结果就是换个发行版就迷路。想真正掌握这个技能，得先理解Linux从按下电源键到出现登录界面之间发生了什么，理解我们改的那个参数究竟动了哪一环。

2.1 GRUB是第一个"裁判"

计算机通电后，BIOS/UEFI固件先起，做基本硬件自检，然后根据启动顺序找可引导设备。找到磁盘后，把控制权交给引导加载程序，最常见的就是GRUB 2。GRUB的工作是向内核传递启动参数、加载内核镜像和initramfs（初始内存文件系统）。

我们在重置root密码时编辑GRUB菜单，按e进入编辑模式，实际上就是在修改内核启动时接收的参数。打个比方：GRUB是一个投递员，把内核这个人送进"城市"（系统），我们改了投递单上的目的地，让内核以另一种模式启动。

2.2 initramfs的作用与"单用户模式"的本质

内核被加载后，它自己还不能直接挂载根文件系统——因为根文件系统所在的磁盘可能涉及驱动、LVM逻辑卷、RAID阵列等，内核本身没有这些驱动。所以内核会先加载initramfs，这是一个小型的内存文件系统，里面包含必要的驱动和工具，完成"真正根文件系统的挂载准备"。

传统SysV init时代，内核参数里加一个s或single，init进程就会直接进入单用户模式，直接给你一个root shell。但到了systemd时代，情况变了一些：systemd会检查内核参数中的systemd.unit=，如果指定rescue.target就会有类似单用户模式的效果。现代主流发行版使用的方案通常是rd.break或init=/bin/bash，它们分别在initramfs阶段和根文件系统挂载后打断启动流程，让你拿到shell。

2.3 修改启动参数的两个经典打断点

这里的核心思路很简单：让内核在启动过程中停在一个无认证约束的、可控的shell环境里，然后手动完成密码重置操作。

第一种打断点：rd.break。这个参数是dracut框架（RHEL/CentOS/Fedora系都用它生成initramfs）提供的。内核解析到rd.break时，会在initramfs完成根文件系统挂载之前停下来，进入一个内存根环境，给你一个shell。在这个shell里，你看到的是initramfs的临时环境，真正的系统根目录被挂载在/sysroot目录下。需要chroot /sysroot切进去再执行passwd。

第二种打断点：init=/bin/bash。这个参数告诉内核：你启动流程不用走完整的init/systemd了，直接运行/bin/bash。但这发生时根文件系统通常还没有挂载，或者以只读方式挂载。你需要手动挂载根分区，再重置密码。

两种方式各有利弊，后面我会结合具体发行版详细说。

2.4 SELinux：一个单独要处理的环节

如果你用的是RHEL/CentOS系，在重置密码后重启，很可能遇到一个诡异现象：密码改成功了，但系统就是登录不进去，或者登录进去后各种服务起不来。原因出在SELinux的文件安全上下文上。

当你用chroot方式修改/etc/shadow时，新旧文件的SELinux标签可能不一致，导致SELinux拒绝某些进程访问。更麻烦的是，有些教程会让你在重启前执行touch /.autorelabel——这个操作会触发系统在下次启动时全盘重建安全上下文，如果机器文件很多，这个重建过程非常漫长，而且处理不好反而容易把系统的标签搞乱。

我的建议是：能免则免，只有在确认SELinux策略异常时才使用。下面实操部分会讲具体怎么处理。

3. 两条最稳的实操路线：rd.break与init=/bin/bash的完整流程

现在进入实际操作环节。我会用两个主流发行版家族为例：CentOS/RHEL系（使用dracut和SELinux）和Ubuntu/Debian系（使用initramfs-tools）。这两条路线覆盖了绝大多数服务器场景，掌握了它俩，基本就能应对各类发行版。

3.1 方案一：rd.break（适用于CentOS/RHEL/Fedora系）

第1步：启动并进入GRUB编辑界面

把机器开机（或重启），在GRUB菜单出现时，选中要启动的内核条目，按下e键进入编辑模式。注意GRUB菜单有时显示时间很短，可以开机后立刻连按方向键锁住菜单不往下走。

第2步：定位内核启动参数行

找到以linux16或linux开头的那一行，这行包含内核镜像路径和一堆参数，比如quiet、splash、rhgb等。把光标移动到行尾。

第3步：追加rd.break参数

在行尾加一个空格，然后输入rd.break。如果要顺便关掉SELinux（推荐在第一次重置时做，后面再说为什么），再加一个空格输入selinux=0。改完后按Ctrl+X或F10引导启动。

第4步：进入shell并挂载根文件系统

系统会启动到initramfs阶段后在断点处停下来，出现类似switch_root:/#的提示符。此时执行：

bash复制mount -o remount,rw /sysroot

这一句的意思是：/sysroot就是即将成为系统根目录的真实文件系统，但它当前是以只读方式挂载的，我们先重新挂载为可读写。如果你不做这一步，后面chroot进去后所有写入操作都会被拒绝。这是最常见的失败点，很多人没执行这一步就干着急。

第5步：chroot切换到真实根环境

bash复制chroot /sysroot

chroot会把当前shell的根目录切换到/sysroot，相当于你进入了真实系统环境。此时我们可以直接操作系统的用户数据库。

第6步：重置密码

bash复制passwd root

系统会提示你输入两次新密码。输入时有几个注意点：

• 终端不显示任何字符是正常的，不要以为键盘坏了，其实只是密码输入不回显。
• 如果系统启用了密码复杂度策略（PAM的pwquality模块），过于简单的密码会被拒绝，比如纯数字、太短的密码。遇到这种情况就用更复杂的密码组合。

第7步：处理SELinux标签

这里要看情况。如果你在第3步加了selinux=0，那么重启后SELinux策略不会生效，你可以正常进入系统。但我建议尽量恢复SELinux的正常状态，否则系统的安全防护出现漏洞，后面出了事更难排查。

操作方法是：退出chroot（执行exit），回到initramfs环境，然后输入reboot -f强制重启。重启后如果一切正常，直接登录即可。如果发现SELinux导致登录异常，再执行：

bash复制touch /.autorelabel

并重启。不过这个命令会触发一次全局重标，耗时可能从几分钟到半小时不等，视机器文件数量而定。我个人的建议是：只有在确认SELinux上下文有问题时才用autorelabel，不要盲目执行。

第8步：验证

登录成功后，第一时间验证权限和基本功能：

bash复制id
whoami
getenforce

getenforce应该输出Enforcing或Permissive，如果它显示Disabled，说明你对SELinux的配置有永久变更，需要检查/etc/selinux/config文件里的SELINUX=行。

3.2 方案二：init=/bin/bash（适用于Ubuntu/Debian系）

Ubuntu Desktop/Server和Debian系的操作略有不同，主要是GRUB的启动参数格式和控制台选项不同。

第1步：进入GRUB编辑模式

同方案一，开机进GRUB菜单后按e。Ubuntu的GRUB菜单可以按住Shift键强制显示（如果设置了GRUB_HIDDEN_TIMEOUT），也可以开机后不停按Esc。

第2步：修改linux行

找到linux开头的那行（通常以vmlinuz路径开头），行尾追加：

code复制init=/bin/bash

如果系统使用[UEFI]启动且开启了安全启动，某些情况下可能需要同时添加nouveau.modeset=0等参数，但一般情况不需要。改完后按Ctrl+X启动。

第3步：挂载根文件系统

此时系统启动到bash后，根文件系统是只读的。先检查一下挂载情况：

bash复制mount | grep " / "

通常显示为/dev/sda1 on / type ext4 (ro,relatime)。然后重新挂载为可写：

bash复制mount -o remount,rw /

注意这里和rd.break方案不一样——rd.break挂载的是/sysroot，这里直接/就是真实根目录，因为内核已经把根挂载上来了，只是只读。

第4步：重置密码

bash复制passwd root

Ubuntu默认情况下root账号是锁定状态（密码为!），如果你只想让root能登录，需要解锁：

bash复制passwd -u root

大部分Ubuntu服务器场景中，你只需要重置当前有sudo权限的用户的密码，不需要解锁root——你可以像这样重置用户密码：

bash复制passwd ubuntu

如果你想给root设置密码并允许登录，执行完passwd root后还要确认/etc/ssh/sshd_config里PermitRootLogin的值是否允许root通过SSH登录，否则就算密码对了也连不上。

第5步：重启

bash复制exec /sbin/init

或者：

bash复制exec /sbin/reboot -f

注意：在init=/bin/bash环境下，直接执行reboot有时会卡住或提示找不到命令，用exec替换当前shell更可靠。

3.3 两种方案的对比与选型建议

选型原则其实不难：你手上是什么发行版就用对应惯用方案。CentOS系用rd.break稳如老狗，Ubuntu用init=/bin/bash更直接。反过来用也不是不行，但可能遇到更多环境差异问题，没必要给自己添麻烦。

3.4 麒麟系统等国产发行版的重置思路

相关热搜词里出现了"麒麟系统重置密码"，这里多说一嘴。银河麒麟、中标麒麟等国产Linux发行版，绝大多数是基于Ubuntu或CentOS的定制版本，底层使用的是标准的内核和GRUB。因此重置思路完全一致：要么走rd.break（CentOS系底子），要么走init=/bin/bash（Ubuntu系底子）。

唯一需要留意的是，麒麟可能自带一些定制的PAM认证模块或安全增强策略，重置密码时如果被拒绝，检查一下是否触发了复杂性要求。另外，麒麟系统的/etc/shadow格式与标准Linux完全兼容，直接passwd不会遇到兼容性问题。

4. 实际踩坑记录：挂载、SELinux、密码策略那些容易翻车的环节

单看操作步骤，整个流程并不长，但实操中翻车率非常高。我见过太多同事卡在同一个环节，这里把最容易出问题的几个点单独拎出来讲，按我踩过的坑逐一说明。

4.1 挂载只读导致"passwd执行成功但一切都没变"

我第一次用rd.break方案时，进shell后直接执行chroot /sysroot，然后passwd root，系统提示设置成功。重启后一登录，发现密码还是旧密码，整个人蒙了。后来才反应过来：/sysroot在默认情况下是以只读方式挂载的，你执行passwd时文件系统层已经把写入操作缓存住了，表面的成功提示其实只是镜像了一次"假写入"。

这个问题在init=/bin/bash方案里同样存在，因为根文件系统默认也是只读的。

排查方法很简单：执行修改操作前，用mount | grep " / "或findmnt /sysroot看一眼挂载参数，确认是rw而不是ro。如果发现是只读，立刻执行我上面写的mount -o remount,rw。这一步做完，后面才能少走弯路。

另外提一个进阶操作：如果你不确定根分区是哪个设备，可以通过blkid或pvs、lvs查看分区和逻辑卷信息。实在不行，在rd.break环境里执行lsblk，会列出一目了然的块设备树。

4.2 SELinux上下文没弄好，密码对了也进不去

这是一条隐藏很深的坑。用chroot方式操作/etc/shadow时，很多教程会让你先执行touch /.autorelabel，保证SELinux的标签正确。但我遇到过不止一次：执行了autorelabel后，系统重启时自动重标卡在一个服务上，进度条卡了半小时，最后强制断电重启反而把系统搞成了需要手动修复的状态。

后来我总结了一套更安全的分层策略：

1. 其实在rd.break方案里，如果initramfs是标准dracut生成的，chroot /sysroot后对/etc/shadow的修改，其SELinux标签会被动态继承或自动修正。多数情况下不需要autorelabel。
2. 如果重启后确实出现异常，先不要急着autorelabel。进入单用户模式，手动检查一下特定文件的上下文：

bash复制ls -Z /etc/shadow

正常显示应该是system_u:object_r:shadow_t:s0。如果标签不对（比如变成了etc_t），用以下命令手动修正即可：

bash复制chcon -t shadow_t /etc/shadow

3. 只有在多个文件标签都错乱、难以手动修正时，才考虑touch /.autorelabel全局重建。

4.3 密码策略拦截：PAM pwquality的"暗算"

RHEL/CentOS 8之后，系统默认启用了pwquality密码质量模块。重置密码时如果你输入的新密码太简单（全数字、纯字母、长度太短），passwd会直接拒绝，并提示类似"密码未通过字典检查"的信息。

遇到这种情况，常规做法是输入更复杂的密码——比如大小写字母加数字加符号混搭。如果确实处于紧急环境，需要临时绕开策略，可以编辑/etc/pam.d/passwd或/etc/security/pwquality.conf，但实际操作中没有必要，因为你应该设一个足够强的root密码。

强密码不是让你记不住，而是让你用过一次之后放到密码管理器里，或者直接改用SSH密钥登录，root密码只是最后的兜底。

4.4 重置后突然"所有普通用户都登录不了"

这个现象比较玄学，但也遇到过。起因是你在chroot环境下执行的不只是passwd，还可能顺手修改了/etc/sudoers或其他认证文件，导致权限混乱。如果发生这种情况，不要慌，再次进入单用户模式，检查并修正相关文件权限：

bash复制ls -l /etc/shadow
ls -l /etc/sudoers

正常权限应该是：/etc/shadow为-rw-------（600）且属主root:shadow，/etc/sudoers为-r--r-----（440）且属主root:root。如果权限不对，用chmod和chown修正。

这类问题多数源于操作时不够专注，把命令执行到了错误的目录或文件上。重置密码时尽量只执行passwd和必要的挂载命令，不要节外生枝。

5. systemd时代的新变化：单用户模式已不是当年的单用户模式

很多老运维习惯用传统方法：内核参数加个s或single，然后期待直接掉进root shell。这个方法在SysV init时代一直是可行的，但在systemd时代，情况变得微妙。

5.1 systemd对single参数的映射

systemd不会直接把single解释为"给我root shell"，而是把它映射为rescue.target。rescue.target是一个特殊的系统状态：会启动必要的基础服务，让系统进入一个"勉强能用"的维护模式，然后尝试按需启动一些必要的挂载（比如/etc/fstab中配置的文件系统）。

关键差异在于：rescue.target启动过程中，系统可能尝试加载/挂载一些服务，如果某个服务在启动时失败，你可能会被卡在服务启动脚本上，而不是顺利拿到shell。此外，在某些systemd配置下，rescue.target会要求你输入root密码——这就尴尬了，你本来就是因为忘密码才走这条路，它却反过来问你要密码。

所以我的建议是：在systemd环境里，放弃single参数，改用rd.break或init=/bin/bash。这两个参数绕过了systemd的完整启动流程，直接给你一个可操作的shell，干扰因素最少。

5.2 journald与日志:重置密码后你会留下哪些痕迹

有些运维朋友会有"是否会被发现"的顾虑。这里讲清楚：系统会非常准确地记录你什么时间通过什么方式重置了密码。本机登录日志里有痕迹，审计日志（/var/log/audit/audit.log）里如果启用了相关规则，也会记录SELinux上下文和账号变化。last、lastlog、journalctl都能看到相关信息。

对于合法管理场景，这些日志无非是"root密码于某时被重置"的记录，正常不过。但对于非法的操作，这是铁证。所以再次强调：这个技能只允许在合规场景使用。

5.3 一个防止"系统起不来"的保底习惯

在重置密码后，不要直接重启走人。有个习惯我坚持了很多年：先用sync命令把缓存数据写盘，再重启。在执行passwd修改了/etc/shadow之后，写操作可能还在缓存里，执行一次sync确保落盘，能避免意外断电导致的文件系统损坏。这个动作虽然简单，但关键时刻能救命。

6. 重置完成后的一系列收尾操作：别改完密码就急着下班

很多人完成密码重置就以为大功告成了，其实真正的重要工作在重置之后。一个负责任的运维，在重置root密码后至少要确认以下几件事。

6.1 确认新密码能登录，并且关键服务依赖正常

重启后不要急着断开控制台，先完整执行一遍登录验证：

bash复制ssh root@localhost

如果本地SSH能登录，再检查关键服务状态：

bash复制systemctl status sshd
systemctl status network
systemctl status docker

这里要注意：如果是通过rd.break方案重置的密码，即使密码改了，某些服务（比如数据库、Web服务）如果依赖文件的SELinux上下文，也可能异常。观察一下/var/log/messages或journalctl -xe是否有异常输出。

6.2 检查SSH密钥登录是否受影响

服务器日常管理通常用SSH密钥登录，root密码只是最后的备用通道。重置密码本身不影响密钥登录，但如果你在重置过程中意外修改了/etc/ssh下的文件权限，或者改动过/root/.ssh/authorized_keys，密钥登录就会失效。

建议顺手检查：

bash复制ls -l /root/.ssh/authorized_keys

权限应为600，属主root:root。如果权限不对，用chmod 600修正。

6.3 记录密码并规划长期方案

把密码记在脑子里不是好习惯。更靠谱的做法是把密码放到团队的密码管理器（比如Vaultwarden、Bitwarden、KeePass）里，保密的同时方便授权同事取用。如果机器数量多，建议尽早部署统一身份认证或配置SSH密钥登录，让root密码退化为"应急通道"。

6.4 考虑给GRUB加上保护

这里讲一个很多人忽略的细节：前面整条重置路径最大的突破口是"能进GRUB编辑菜单"。如果一个设备可以被物理接触，任何人在GRUB界面按e都能接管系统。所以，对生产环境来说，给GRUB设置密码保护是很有必要的。

GRUB 2的密码保护操作：

bash复制grub2-setpassword

执行后按照提示输入密码，GRUB会在启动配置文件里生成加密的密码条目。此后进入GRUB编辑模式需要先按p输入密码。这样即使攻击者能碰到机器，也不能轻易通过改启动参数来重置root密码。

Ubuntu/Debian系可以用：

bash复制grub-mkpasswd-pbkdf2

然后把生成的哈希写入/etc/grub.d/40_custom，再执行update-grub。

做好这步之后，本文介绍的密码重置方法就会失效——这正说明你前面的修改密码操作不再是单点突破，整体安全闭环才算完整。

6.5 另一个相关场景：MySQL的root密码遗忘了怎么办

看到热搜词里有"mysql忘记root密码"，顺手提一下。这类问题也常见，但操作路径和系统root重置有本质区别——MySQL是应用层服务，不需要碰系统内核参数。常规做法是：

1. 停止MySQL服务
2. 以跳过授权表方式启动：mysqld_safe --skip-grant-tables &
3. 连接后直接执行SQL修改密码：

sql复制ALTER USER 'root'@'localhost' IDENTIFIED BY 'new_password';

4. 正常重启服务

这个方案不需要重启系统，风险也比改内核参数低。不过和系统root密码一样，重置后要记得确认~/.my.cnf里的旧密码是否也需要同步更新，否则一堆脚本会接着报连接失败。

7. 日常维护的几条务实建议：密码管理、灾难预案与合规意识

在前面这些实操内容之外，我想基于自己的维护经验，再聊几句更长远的事。

7.1 密码管理不只是"难记一点"

很多团队选密码的标准是"好记"，这个思路要改。一个安全、可维护的root密码应该是"难猜但好记"的组合。比如用一句只有自己人懂的话的首字母缩写，加上特殊符号和数字。但更重要的是把密码放进统一管理工具，而不是零散地存在个人备忘录里。

另外，密码替换要有策略。不要等出事了才想起来换密码，每隔一段时间主动轮换一次，至少保障root密码这个最后通道不被遗忘。轮换时在团队内部同步，并做好变更记录（比如在运维Wiki里更新，或至少在IM群里留一条记录）。

7.2 灾难预案要扎根在"可执行的文档"里

我猜很多团队的情况是：平时不写文档，出了故障才到处翻别人的博客。与其这样，不如花一个小时把"系统root密码重置"这类高频故障的SOP整理成一篇内部文档，内容包括本文的两种方案、适用发行版、注意事项，以及本团队的服务器密码管理方式。

文档不要求长，但要精确到你能照着操作完成。等真出事时，这篇文档的价值远大于在搜索引擎里临时翻到的任何一篇教程。

7.3 合规与边界意识

最后强调一遍边界。本文所有技术内容的价值前提，是你在维护自己的设备或已获得授权。在实际工作中，请确保所有的密码重置操作都有明确授权依据。很多企业的IT管理制度里对这类操作有明确的审批流程和留痕要求。该走的流程走完再动手，该留的日志留好再做。技术是用来解决业务问题的，不是用来制造麻烦的。

我个人在重置完一批服务器密码之后，会顺手做三件事：更新团队密码库、在运维工单里写清楚变更时间和原因、给下个月值班的同事同步一条"密码已变更，注意更新脚本"的提醒。这些看起来琐碎，但真能帮你在下次故障时少走不少弯路。

这些习惯的价值，会在你半夜再次接到那通"密码忘了"的电话时体现出来。