MIUI 11老机型：TWRP永久固定与无密data分区实战

1. 先把原理捋清楚：MIUI 11 的恢复分区与 data 加密

手上还留着一台 MIUI 11 时代的老机器，扔了可惜，当备用机又嫌系统臃肿——这种场景下，刷入 TWRP 并做成无密 data 分区，几乎是所有后续折腾的前提。TWRP 是第三方恢复环境，能让你在不进系统的情况下备份、刷包、改分区；无密 data 分区指的是把 /data 从强制加密状态改成不加密（或可选加密），让 TWRP 不用输密码就能直接读写数据分区。这两件事单独做都不难，难的是"永久"——很多人刷完 TWRP，重启一次就变回官方 recovery；好不容易解密了 data，开机又被系统重新加密。这篇就把这两个"回滚"机制拆开讲透，再给一套可以直接照抄的操作流程。

先说明适用范围：本文针对的是搭载 MIUI 11、Android 9 或 Android 10 底层、采用 A-only 分区且带独立 recovery 分区的机型。A/B 无缝分区机型和动态分区（super 分区）机型的处理方式完全不同，后面会用表格区分。所有操作都建立在你对自己设备拥有完全处置权、并且已经接受"解锁会清空数据、部分应用可能受限"这个前提之上。刷机不是刚需，但如果你想把这台老机器当备份机、测试机、或者单纯想让它多活两年，这套流程值得花两个小时搞明白。

1.1 为什么 TWRP 会"自己消失"

很多人第一次刷 TWRP 的体验是这样的：fastboot 刷进去，提示 OKAY，重启进 recovery，TWRP 正常；然后正常开机用了一天，第二天想再进 recovery，发现变回了官方的 MIUI 恢复界面。这不是刷失败了，而是 MIUI 有一套"恢复分区自愈"机制在起作用。

具体来说，系统分区里通常留着两个文件：一个是recovery-from-boot.p，一个是install-recovery.sh（有的版本放在/system/bin/，有的在/system/etc/）。开机过程中，系统会检查 recovery 分区的校验值，如果发现和预期不一致，就用recovery-from-boot.p里打包的官方 recovery 镜像把分区重新写回去。这个设计的初衷是保证 OTA 升级的可靠性，但对刷机的人来说就是个"自动还原"。

所以"永久固定"的本质不是刷得多深，而是把这条回写链掐断。你要做的就是在 TWRP 里把这两个文件删掉或者改名，让系统开机时找不到还原源。听起来很简单，但实际操作里有三个坑：第一，Android 10 的 system-as-root 结构导致路径变了，很多人按老教程找不到文件；第二，system 分区默认是只读的，不关掉 dm-verity 根本挂不上读写；第三，有些机型的这两个文件在 vendor 分区而不是 system 分区。这三个坑在后面对应章节会逐个拆。

注意：删除回写文件属于修改系统分区，会破坏 AVB 校验，部分机型必须同时关闭 verity 和 verification 才能正常开机，否则会卡在开机动画。

1.2 data 加密的两种形态与无密 data 的含义

data 分区加密这件事，得先分清 FDE 和 FBE。FDE 是全盘加密，整个 /data 一把密钥，开机时输入密码解锁；FBE 是基于文件的加密，每个文件有独立密钥，系统启动到一半就能读部分数据，锁屏后才真正锁住。MIUI 11 这一代基本都切到了 FBE，底层用的多是硬件加密引擎，密钥材料放在 TEE 里。

FBE 带来的直接后果是：TWRP 想读 /data，必须能跟系统的 keymaster 服务对上话，拿到解密密钥。而第三方 recovery 里的 keymaster 实现往往和原厂有差异，尤其是那些用了定制加密方案的机型，结果就是 TWRP 里 /data 显示 0MB、挂载报错、或者提示"Unable to mount /data"。你能做的只有两件事：要么找一个明确支持该机型 FBE 解密的 TWRP 版本，要么干脆把 data 格式化成不加密状态。

无密 data 分区就是后者。它的实现方式是在 fstab 文件里，把 data 分区的挂载参数从"强制加密"改成"可选加密"或者干脆去掉加密标志。fstab 是 Android 启动时告诉内核"每个分区怎么挂、挂哪里、要不要加密"的配置文件，位置通常在 boot 分区的 ramdisk 里，或者在 vendor 分区的/vendor/etc/下。改掉这一行，系统开机时就不会再给 data 加密；已经加密过的 data 必须格式化一次才能生效。

这里必须讲清楚代价：无密状态下，任何人拿到你的手机，把存储拆出来或者进 recovery 就能直接读全部数据，锁屏密码形同虚设。所以无密 data 适合测试机、备用机、折腾机，不适合当主力机存放敏感信息。我在自己的备用机上做无密，但主力机从来不动这个。

1.3 三种分区布局，方案完全不同

同样是 MIUI 11，不同机型的分区结构差异很大，照搬教程十有八九要出事。先看下面这张表，对照自己的设备特征判断属于哪一类。

判断方法很简单，手机连电脑开 ADB，执行下面几条命令：

adb shell getprop ro.boot.slot_suffix # 有返回值说明是 A/B adb shell getprop ro.boot.dynamic_partitions # true 说明是动态分区 adb shell ls /dev/block/bootdevice/by-name/ # 找有没有 recovery

三条命令跑完，基本就能定性。我手上这台老机器是 A-only、无动态分区、by-name里明确有 recovery，属于表格第一类，也是本文实操部分的主线。如果你是第二类或第三类，原理可以借鉴，但具体命令必须换成对应机型的方案，硬套会变砖。

1.4 这台机器的方案选型与顺序设计

方案定下来之前，先想清楚操作顺序，因为顺序错了会白干。常见的错误顺序是：先刷 TWRP，然后重启进系统，再想解密——结果 TWRP 被回写覆盖了，只能重刷一遍；或者先格式化 data，再刷 TWRP，结果格式化时用的还是官方 recovery，做完等于没做。

正确的顺序应该是：解锁 bootloader → 刷入 TWRP → 不重启直接进 TWRP → 格式化 data → 刷禁用加密补丁 → 删除 recovery 回写文件 → 重启验证。这个顺序的核心逻辑是：整个流程都在 TWRP 环境里完成，中途绝不进入官方系统，避免任何一次开机触发回写或重新加密。

还有一个关键决策点：先解密还是先固定 TWRP。我的建议是先解密。原因是格式化 data 需要在 TWRP 里做，而 TWRP 一旦被覆盖就得重刷，重刷又可能触发新的校验问题。先把 data 处理干净，再慢慢处理回写文件，容错空间更大。反过来的话，你删完回写文件重启，系统可能因为 data 加密状态和 fstab 不匹配而卡启动，排查起来更麻烦。

2. 准备工作：解锁、判型、备份

这一章看着琐碎，但实际出问题最多的地方就在这儿。我见过太多人卡在解锁环节，或者备份没做全，格式化完才发现几年的照片没了。准备工作做扎实，后面每一步都会顺很多。

2.1 工具与文件清单

先把要用的东西一次性备齐，避免操作到一半去找文件。下表是我常用的清单，按重要程度排序。

TWRP 镜像的选择有个硬标准：必须明确标注支持你的 Android 版本和加密类型。 MIUI 11 横跨 Android 9 和 Android 10，这两个版本的 fstab 位置和加密方式都有差异，用错版本轻则挂不上 data，重则刷完黑屏。如果找不到明确标注的版本，就去翻该机型相关的技术讨论区，看别人实测能用的版本号，别自己猜。

注意：下载完镜像先核对文件大小和校验值，很多"刷完没反应"的案例，根源是镜像下载不完整。

2.2 分区布局怎么判断

上一章给了三条命令，这里补充几个更细的判断依据，帮你确认自己没有误判。

第一，看 fastboot 的反馈。执行fastboot getvar current-slot，如果返回current-slot: a之类的内容，说明是 A/B 机型；返回unknown variable或者报错，基本就是 A-only。第二，看官方固件包的目录结构，里面有独立recovery.img的是 A-only，只有boot.img的通常是 A/B 或 recovery 集成在 boot 里。第三，进官方 recovery 看界面，MIUI 的官方恢复功能很简陋，只有清数据和重启几个选项，这本身不能判断分区，但能确认 recovery 分区确实存在且可被替换。

还有个容易忽略的点：system-as-root。Android 10 开始，system 镜像挂载为根目录，实际文件在/system/system/下面。这意味着你在 TWRP 里挂载 system 之后，找recovery-from-boot.p的路径要写成/system/system/recovery-from-boot.p，而不是老教程里的/system/recovery-from-boot.p。找不到文件的时候，先怀疑路径，别怀疑文件不存在。

2.3 数据备份的靠谱做法

备份这件事，我的原则是"三条腿走路"，任何一条失效都还有退路。

第一条腿是系统自带的云备份，把联系人、短信、通话记录、应用列表同步上去。这条最省事，但恢复慢，而且大文件（照片、视频、微信聊天记录）通常不在里面。第二条腿是手动拷贝，把/sdcard下的 DCIM、Pictures、Download、微信目录整个拖到电脑上。这一步别偷懒，格式化 data 会把这些全清掉，而且 TWRP 的格式化是不可恢复的。第三条腿是应用数据备份，用具备备份功能的管理工具把关键应用的数据导出来，或者至少把账号密码记在别的地方。

有个细节值得说：解锁 bootloader 本身就会清空一次数据，很多人是在解锁之后才想起来备份，那时候已经晚了。所以备份要在解锁之前做，而且做完要验证——随便打开一个照片看看能不能正常显示，别拷了一半就拔线。

2.4 解锁与风险边界

解锁 bootloader 是整套流程的门票，没有它，fastboot 刷任何分区都会提示权限不足。解锁的通用流程是在开发者选项里打开 OEM 解锁和 USB 调试，然后用官方提供的解锁工具申请。不同机型等待时间不一样，有的即时通过，有的要等几天。

解锁前必须做的两件事：退出系统账号、关闭查找设备功能。 这两步不做，解锁后开机可能直接卡在激活验证界面，进不去系统也没法刷机，只能干等。我遇到过这种情况，最后是通过官方救砖工具整包重刷才恢复，折腾了大半天。

风险边界也要提前想清楚。解锁后设备会失去官方保修（如果有的话），部分金融类应用可能因为设备状态异常而限制功能，系统 OTA 可能失效或需要重新上锁才能更新。这些都是已知代价，接受不了就别开始。另外提醒一句，本文所有操作仅适用于你自己拥有处置权的设备，别拿别人的机器练手。

3. TWRP 写入与永久固定的实操

准备工作做完，进入正题。这一章按操作顺序展开，每一步都说明"为什么这么做"，你照着做的时候心里有数，遇到变体也能自己判断。

3.1 第一步：把 TWRP 写进 recovery 分区

先让手机进入 fastboot 模式，通常是关机后按住音量下加电源键，屏幕出现特定界面后用数据线连电脑。执行fastboot devices确认设备被识别，返回一串序列号就说明通了；返回空行说明驱动或线有问题，先解决这个再往下走。

刷入命令本身很简单：

fastboot flash recovery twrp-3.x.x-A.img

但这里有个细节：部分机型需要先擦除原分区再写入，否则可能校验失败。擦除命令是fastboot erase recovery，执行完再 flash。擦除之后设备会处于"recovery 分区为空"的状态，这时候千万别直接重启进系统，因为系统检测到分区异常可能会触发一些奇怪的行为。正确做法是紧接着执行刷入，或者用fastboot boot直接从镜像临时启动。

fastboot boot twrp-3.x.x-A.img

fastboot boot不写入分区，只是把镜像加载到内存里跑一次。它的价值在于：让你在真正写入之前验证这个 TWRP 版本能不能正常启动、能不能识别你的分区。如果临时启动都黑屏，那就别刷了，换版本。这个"先试后刷"的习惯，帮我省过好几次重刷固件的时间。

3.2 第二步：先进 TWRP，别急着开机

刷完或者临时启动后，手机会进入 TWRP 界面。这时候第一件事是确认它认不认你的分区：进 Wipe 菜单看 data 分区大小是不是正常数值（不是 0MB），进 Mount 菜单看 system、vendor 能不能挂载。如果 data 显示 0MB，说明这个 TWRP 解不了你的加密，后面格式化 data 的操作可能失败，得先换 TWRP 版本。

第二件事是确认 system 能不能挂载为读写。默认是只读的，需要在 Mount 里勾选 System 并确保 "Mount system partition read-only" 没被选中。如果勾了还是只读，就得处理 dm-verity 校验，这个在 3.4 节讲。

这一步最重要的原则是：不要重启进系统。 TWRP 刚刷进去的时候是"新鲜"的，一旦进系统，回写机制就可能启动。所以进 TWRP 之后直接把后续步骤做完，包括格式化 data、刷补丁、删回写文件，一气呵成。中途如果必须重启（比如补丁要求重启生效），也要重启回 recovery 而不是重启进系统。

3.3 第三步：掐断官方 recovery 回写链

这是"永久固定"的核心。核心思路是在 TWRP 里找到那两个回写文件并删掉。先挂载 system 分区，然后用 TWRP 自带的终端或者 ADB shell 操作。

# 在 TWRP 终端里执行 mount -o rw,remount /system find /system -name "recovery-from-boot.p" 2>/dev/null find /system -name "install-recovery.sh" 2>/dev/null

find的好处是不用管路径变体，system-as-root 结构下它能自动搜到/system/system/里的文件。找到之后执行删除：

rm -f /system/system/recovery-from-boot.p rm -f /system/system/bin/install-recovery.sh

删完记得再跑一次 find 确认，同时检查 vendor 分区里有没有同名文件（有些机型把还原源放在 vendor）。如果 system 挂载为读写失败，说明 dm-verity 还开着，先跳到 3.4 节处理校验，回来再删。

注意：不要只改文件名不删，某些校验逻辑会扫描备份文件；也不要把文件删了却忘了清缓存，个别机型会从缓存里恢复。

3.4 第四步：处理 vbmeta 与 dm-verity 校验

AVB 2.0 是 Android 的启动完整性校验机制，它通过 vbmeta 分区里的签名，逐级校验 boot、system、vendor 等分区的哈希值。你改了 system 分区的内容，校验就对不上，设备可能拒绝启动或者卡在开机动画。

解决办法是关闭校验。标准做法是提取同版本官方固件里的vbmeta.img，然后用带参数的方式刷回去：

fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img

这两个参数的含义要分清：--disable-verity关的是 dm-verity，也就是块级别的完整性校验，不关它 system 分区挂不上读写；--disable-verification关的是 AVB 签名校验，不关它改了分区就开不了机。两个都要关，只关一个会出现"能挂载但开不了机"或者"能开机但改不了分区"的半吊子状态。

部分 TWRP 版本内置了关闭校验的功能，在 Advanced 或者 Mount 菜单里能找到类似 "Disable DM-Verity" 的选项，效果等价，操作更省事。但要注意，这个操作同样会修改 vbmeta 状态，做完之后系统 OTA 基本就废了，后面要靠整包刷机来更新。

3.5 第五步：验证"永久"是否成立

所有操作做完，重启进系统，正常使用一段时间（至少经历一次完整开关机），然后关机，手动进入 recovery。如果进的是 TWRP 而不是官方恢复界面，说明回写链掐断成功。

第二次验证更严格：用fastboot boot之外的方式，也就是完全靠按键进入。因为有些情况下 fastboot 命令会临时覆盖分区状态，用按键进的才是真实状态。如果按键进去还是 TWRP，那基本可以确认固定住了。

第三次验证是检查文件是否真的没了：进 TWRP 挂载 system，再跑一次find，确认搜不到那两个文件。如果文件又出现了，说明有别的还原机制（比如某个开机脚本），需要进一步排查。我在一台机器上遇到过文件被重新生成的情况，最后发现是 vendor 分区里有个备份副本，删掉 vendor 里的才彻底干净。

4. 无密 data 的实现：从格式化到 fstab 改造

TWRP 固定住之后，处理 data 加密。这一章的两个方案，一个是刷补丁，一个是手动改 fstab，前者省事，后者可控，建议先试补丁，不行再手动。

4.1 格式化 data 到底做了什么

先纠正一个常见误区：TWRP 的 Wipe 菜单里有两个容易混淆的选项，一个是 "Format Data"，一个是 "Advanced Wipe → Data"。这两个完全不是一回事。

Advanced Wipe 里的 Data 是普通格式化，它只清掉文件系统的内容，加密的元数据（也就是那个"footer"）还留在分区末尾。格式化完重启，系统一看加密标志还在，照样按加密分区处理，你还是得输密码。而 Format Data 会连加密元数据一起清掉，并在分区上重建一个干净的文件系统，输入 yes 确认后执行，这才是真正的"去加密"。

操作路径是：TWRP 主界面 → Wipe → Format Data → 输入yes→ 确认。执行完你会看到一堆 "Formatting Data using make_ext4fs" 或者 "mkfs.f2fs" 的日志，最后提示 successful。

注意：Format Data 会清空整个 /data，包括内部存储里的所有文件。这一步之前必须完成备份，没有例外。

4.2 补丁方案：一键禁用强制加密

格式化之后，data 是干净的，但系统开机时还会按照 fstab 里的配置重新加密。所以必须改 fstab，让系统知道"这个分区不要加密"。补丁包做的就是这件事。

常见补丁的工作流程是：解包 boot 分区或者挂载 vendor，找到 fstab 文件，把里面的强制加密标志替换掉，再重新打包刷回。使用时在 TWRP 里选择 Install，选中 zip 包滑动刷入即可。刷完它会输出日志，告诉你改了哪个文件、改成了什么。

刷补丁有两个前提：一是必须先格式化 data，二是补丁版本要匹配你的系统版本。 MIUI 11 的 fstab 格式在不同小版本之间可能有微调，用错版本的补丁可能改不到正确的位置，表现为"刷成功了但开机还是加密"。判断方法是开机后进系统设置看存储加密状态，或者干脆再进 TWRP 看 data 要不要密码。

如果补丁刷完还是加密，别急着重刷，先看日志里是否有 "fstab not found" 之类的提示。这种情况说明你的机型 fstab 位置特殊，得走手动方案。

4.3 手动方案：拆 boot 改 fstab

手动改 fstab 的难点在于找到正确的文件。Android 10 的启动流程里，fstab 可能出现在三个位置：boot 分区的 ramdisk 根目录、ramdisk 的first_stage_ramdisk子目录、以及 vendor 分区的/vendor/etc/。哪个生效取决于机型的启动配置。

先说 boot 分区的处理。用镜像解包工具把 boot.img 拆开：

magiskboot unpack boot.img

解包后会得到一个 ramdisk 目录，在里面找fstab.qcom或者fstab.<平台名>的文件。用文本编辑器打开，找到 data 那一行，它大概长这样：

/dev/block/bootdevice/by-name/userdata /data f2fs nosuid,nodev,noatime,inline_xattr,forceencrypt=footer ...

关键是forceencrypt=footer这个参数。把它改成encryptable=footer，表示"可以加密但不强制"；或者直接删掉这个参数，表示完全不加密。改完重新打包：

magiskboot repack boot.img new-boot.img fastboot flash boot new-boot.img

如果 fstab 在 vendor 分区，就不用拆 boot 了，直接在 TWRP 里挂载 vendor 为读写，用文件管理器或者终端改/vendor/etc/fstab.qcom，改完保存。这种改法更简单，但要注意 vendor 分区受 dm-verity 保护，必须已经关闭校验才能写入成功。

手动改的风险点在于格式。fstab 的每一行是空格分隔的字段，多一个空格少一个逗号都可能导致挂载失败，进而开不了机。改之前把原文件复制一份到外部存储，改完用cat命令核对内容，确认参数名拼写正确（encryptable不是encryptble）。

4.4 顺序问题：先解密还是先固定 TWRP

前面提过要先解密，这里说清楚为什么。假设你先删了回写文件、固定了 TWRP，然后重启进系统准备再处理 data——这一步重启会让系统按原 fstab 重新加密 data（如果之前格式化过），等于白做。而如果你先格式化和改 fstab，再删回写文件，整个流程可以一直在 TWRP 里完成，中间不接触官方系统，也就没有重新加密的机会。

还有一个细节：刷补丁和刷 Magisk 的顺序。如果你打算装 Magisk，建议在禁用加密补丁之后刷，因为补丁可能会修改 boot 分区，而 Magisk 也是修改 boot 分区，顺序反了可能互相覆盖。刷完 Magisk 之后再进系统，用 Magisk 应用确认安装状态。

4.5 怎么确认已经无密

验证方法有三个层次。最直观的是进 TWRP，看 data 分区还要不要密码——不要密码直接能浏览文件列表，说明没加密或者加密已解除。第二层是进系统后用 ADB 查属性：

adb shell getprop ro.crypto.state

返回unencrypted就是无密，返回encrypted就是还在加密。第三层是看 fstab 的实际内容，在 TWRP 里把文件 cat 出来，确认forceencrypt已经不在。

三层都过了才算真的成功。只过第一层不够，因为 TWRP 可能只是恰好能解开，系统启动时照样加密。只过第二层也不够，因为某些系统会延迟加密，开机时显示 unencrypted，用一会儿又变了。

5. 常见故障排查与经验

这一章是实际操作中最有价值的部分，很多问题教程里不会写，但你会真实遇到。

5.1 故障速查表

这张表覆盖了我遇到过的大部分情况。实际排查时，先看现象对应哪一行，再按处理方向走，别一上来就整包重刷，那样虽然能救回来，但会丢掉所有已做的配置。

5.2 卡米、卡 fastboot、TWRP 黑屏的应急

卡在品牌动画是最常见的故障。处理思路是先判断是"校验失败"还是"分区损坏"。如果是改完 system 之后第一次开机就卡住，八成是 AVB 校验没过，重新刷一次 vbmeta 并带上关闭参数通常能解决。如果是刷完 boot 之后卡住，可能是 boot 镜像打包有问题，用官方 boot.img 刷回去恢复原状，再重新操作。

卡在 fastboot 界面进不去系统，说明 boot 分区的内容无法被正常引导。这时候 fastboot 还能用，是好事。直接用官方固件包里的 boot.img 刷回去，能开机之后再重新尝试。别在这个时候继续刷其他分区，容易把小问题扩大。

TWRP 黑屏或者花屏，通常是镜像版本不对。有些机型有多个屏幕供应商，TWRP 镜像只适配了其中一种，刷进去就是黑屏但设备其实在运行。解决办法是找该机型专用的、标注支持多屏幕的版本，或者用fastboot boot临时测试多个版本，找到能正常显示的那个再写入。

5.3 OTA 与后续维护

无密 data 加固定 TWRP 之后，系统 OTA 基本就废了。原因有三：OTA 会校验 system 分区完整性，你删了文件校验就过不了；OTA 会覆盖 recovery 分区，TWRP 会被换回官方；OTA 还可能重置 fstab，让 data 重新加密。所以这套方案做完，就要做好"手动更新"的心理准备。

要更新系统的话，正确姿势是：下载完整固件包，在 TWRP 里刷入（注意不要刷包含 recovery 的分区），刷完重新执行关闭校验、删回写文件、刷解密补丁这套流程。这个过程比较繁琐，所以我的建议是：除非有必须修的安全问题，否则这台机器就停在当前版本，别折腾更新。

Magisk 的更新相对简单，但也要注意：某些版本的 Magisk 会重新处理 boot 分区的 fstab，可能覆盖你的解密配置。更新 Magisk 之后，进 TWRP 检查一下 fstab 里的加密参数还在不在，不在就重新刷一次补丁。

5.4 几条踩坑心得

第一条，fastboot boot是你的安全绳。 任何要写入分区的操作之前，先用临时启动测一遍。能正常进 TWRP、能识别分区、能挂载 system，再考虑写入。这个习惯让我至少避免了三次因为镜像不匹配导致的重刷。

第二条，每次改完分区立刻验证，别攒着一起验。 改完 fstab 就查属性，删完回写文件就跑 find，刷完 vbmeta 就开机试。一次改一个变量，出问题能立刻定位到是哪一步。一次改五处再重启，出了问题只能全部重来。

第三条，准备一个"救砖包"。 把官方完整固件、驱动、刷机工具提前放在一个文件夹里，真出事了不用现找。我第一次刷坏的时候，光找匹配版本的固件就花了两个小时，那种焦虑感不想再体验第二次。

第四条，不要相信"一键工具"。 这类工具封装了太多细节，出错时你看不到日志，不知道它改了哪个分区。宁可多敲几行命令，至少每一步的反馈都在你眼前。真出问题，命令行输出的信息就是排查的线索。

第五条，无密 data 的机器别放重要东西。 这话我说了很多遍，但还是有人把工作文档、私人照片放在测试机上。数据安全这件事，加密是最后一道防线，你自己把防线拆了，就得靠使用习惯来补。

最后分享一个我常用的检查脚本思路：把判断分区类型、检查 fstab 参数、查找回写文件这几条命令写成一个 shell 脚本，放在 TWRP 能访问的目录里，每次操作前跑一遍，输出一份当前状态清单。这样你不用记那么多命令，也不会漏掉某个检查项。脚本不用复杂，几条getprop、几次find、一次grep就够了，但它能让你在动手之前对设备的真实状态心里有数。