企业官网建设流程全解析

目录

• 一、基础安卓系统与权限机制
• 二、安卓分区结构详解
  • 2.1 传统分区结构（Android 10 之前）
  • 2.2 Android 10 及之后的动态分区
• 三、Root 权限获取与管理
  • 3.1 传统系统分区修改 Root（System-Mode Root）
  • 3.2 Systemless Root（无系统修改 Root）
  • 3.3 内核级 Root（Kernel-Assisted Root）
  • 3.4 漏洞利用 Root（Exploit-Based Root）
• 四、Root 方式工作原理详解
  • 4.1 传统系统分区修改 Root（System-Mode Root）
  • 4.2 Systemless Root（无系统修改 Root）

随着智能手机的普及和功能的不断扩展，许多安卓玩家开始探索手机的深层次操作，诸如ROOT、Recovery、Bootloader（引导加载器）等术语逐渐走入公众视野。本章为新手入门者提供一份全面的安卓刷机基础指南，阐释相关核心概念、操作流程及注意事项。掌握这些基础知识，不仅可以提升手机性能和个性化，也为后续深度折腾提供坚实的技术基础。

在安卓系统的世界中，ID越深，自由度越高。官方系统旨在保证安全与稳定，用户权限有限（受限于系统权限），许多自定义操作和深度优化都受到限制。为了实现系统的深度控制和软件定制化，必须了解并掌握诸如ROOT、Recovery和Bootloader解锁等关键操作。

基础安卓系统与权限机制

安卓系统架构基于Linux，其权限管理机制类似底层的Linux系统。

安卓系统中的权限大致分为三类：

• 软件权限：第三方应用请求的权限（如摄像头、定位、文件读取），须用户授权。
• 用户权限：普通操作权限（设置锁屏、重启、卸载应用等），由用户在操作时行使，权限较高。
• 超级用户权限（Root）：最高权限，几乎可以控制系统的所有功能，包括修改系统文件、卸载预装软件、硬件调控（如GPU超频、CPU调度）等。

三类权限的对比关系如下表所示：

为帮助新手快速理解刷机与 Root 过程中常见的关键术语，下表汇总了它们的英文全称、中文释义及简要说明：

安卓分区结构详解

传统分区结构（Android 10 之前）

1boot（引导分区）

• 作用：包含 Linux 内核和根文件系统的 ramdisk（初始根文件系统），用于启动 Android 系统。

• 文件系统：原始二进制格式（通常为 Android boot image）。

• 挂载点：不挂载，由 bootloader 加载。

• 说明：刷入自定义内核或修补 boot 镜像（如 Magisk）通常涉及此分区。

2.system（系统分区）

• 作用：存放 Android 操作系统核心文件、系统应用、框架、库等。

• 文件系统：只读，通常为 ext4 或 erofs（只读文件系统，节省空间）。

• 挂载点：/system（或/在 Android 10 之后 system-as-root 设备上）。

• 说明：在 Android 10 之前，system 分区包含大部分系统内容；之后部分内容被拆分到其他分区。

3.vendor（供应商分区）

• 作用：存放硬件相关的驱动、库、固件、HAL（硬件抽象层）实现等，由设备制造商或 SoC 厂商提供。

• 文件系统：ext4 或 erofs，只读。

• 挂载点：/vendor（Android 8.0 以后独立出来，之前可能是/system/vendor）。

• 说明：Android 8.0 引入 Project Treble，将 vendor 与 system 分离，便于系统升级而不影响硬件驱动。

4.userdata（用户数据分区）

• 作用：存放用户安装的应用、应用数据、设置、媒体文件（如照片、音乐）等。

• 文件系统：ext4 或 f2fs（针对闪存优化），读写。

• 挂载点：/data。

• 说明：恢复出厂设置就是擦除此分区的内容。

5.cache（缓存分区）

• 作用：存放系统更新包、临时日志、恢复命令等。

• 文件系统：ext4，读写。

• 挂载点：/cache。

• 说明：在 Android 10 之后，cache 分区被合并到/data/cache，不再单独存在（部分设备仍保留）。

6.recovery（恢复分区）

• 作用：包含独立的恢复系统（Recovery），用于系统更新、恢复出厂设置、清除缓存、安装 OTA 包等。

• 文件系统：原始二进制格式（与 boot 类似）。

• 挂载点：不挂载，由 bootloader 加载进入恢复模式。

• 说明：A/B 分区设备中，recovery 功能被集成到 boot 镜像中，不再单独分区。

7.misc（杂项分区）

• 作用：存放系统设置、引导命令（如是否进入 recovery）、硬件信息等少量数据。

• 文件系统：原始数据或 ext4。

• 挂载点：不挂载。

• 说明：用于 bootloader 与系统之间传递信息。

8.modem / radio / baseband（基带分区）

• 作用：存放无线通信相关的固件（蜂窝网络、Wi-Fi、蓝牙等）。

• 文件系统：原始二进制格式或专用格式。

• 挂载点：不挂载，由内核和系统调用。

• 说明：不同厂商命名可能不同，如modem、radio、firmware。

9.persist（持久分区）

• 作用：保存一些不应随恢复出厂设置而丢失的数据，如传感器校准数据、Wi-Fi MAC 地址等。

• 文件系统：ext4。

• 挂载点：/persist（隐藏，普通应用不可见）。

• 说明：损坏可能导致传感器异常或无法连接 Wi-Fi。

10.efs / nvdata（基带数据分区）

• 作用：存储 IMEI、MEID、序列号等设备身份标识及网络相关配置。

• 文件系统：专有格式。

• 挂载点：不挂载。

• 说明：通常与 modem 分区关联，损坏可能导致设备无法注册网络。

Android 10 及之后的动态分区

Android 10 引入了动态分区（Dynamic Partitions）机制，将system、vendor、product、odm等只读分区合并到一个名为super的大分区中，支持无线升级（OTA）时灵活调整大小。

• super分区包含以下子分区（逻辑分区）：

  • system：系统核心（仍存在，但不再是物理独立分区）。

  • vendor：硬件相关。

  • product：产品定制内容（Android 10 新增）。

  • odm：原始设计制造商定制内容。

  • system_ext：系统扩展（Android 11 新增）。

• 文件系统：这些逻辑分区通常为只读（erofs/ext4），但底层 super 分区是物理分区。

• A/B 无缝更新分区

  为了支持无缝系统更新，从 Android 7.0 开始引入 A/B 分区方案。设备拥有两套关键分区（boot_a/boot_b、system_a/system_b等），更新时写入非活动槽位，重启后切换，失败可回滚。

Root权限获取与管理

ROOT：取得设备的超级用户权限，可自由修改系统文件、硬件参数、自定义 ROM。

Root 方式分为：

传统系统分区修改 Root（System-Mode Root）

将su文件、busybox等工具直接写入/system/xbin或/system/bin，并安装 Superuser 管理应用。

• 特点：

  • 需要解锁 Bootloader 或利用漏洞获得写/system权限。

  • 会修改系统分区，导致 OTA 更新失败或需要完整包升级。

  • 在 Android 4.4 之前非常普遍，之后逐渐被淘汰。

• 现状：现代 Android（8.0+）普遍启用验证启动（Verified Boot）和动态分区，系统分区只读，此类 Root 已基本不可行。

Systemless Root（无系统修改 Root）

不修改/system分区，而是通过修改启动镜像（boot.img）或利用 Magisk 的magiskinit在启动过程中注入su和 Magisk 服务。

• 特点：

  • 保持系统分区完整性，不影响 OTA（需还原 boot 镜像）。

  • 可通过 Magisk Manager 隐藏 Root（MagiskHide/Zygisk），提高兼容性。

  • 支持模块化扩展（Magisk Modules）。

• 现状：当前比较优秀的 Root 方案，广泛支持 Android 6.0 至最新版本。

内核级 Root（Kernel-Assisted Root）

直接在内核空间实现权限提升，不依赖传统su二进制文件。例如 KernelSU 通过内核模块在execve系统调用中授予 Root 权限。

• 特点：

  • 更隐蔽，可绕过部分 Root 检测（尤其内核级检测）。

  • 需要刷入自定义内核或补丁，通常需要解锁 Bootloader。

  • 对内核版本有要求（如 KernelSU 支持 GKI 内核，Android 12+ 设备更友好）。

• 适用场景：追求高隐蔽性和高级定制的用户。

漏洞利用 Root（Exploit-Based Root）

利用系统或芯片漏洞直接获取临时或永久 Root，无需解锁 Bootloader。

• 特点：

  • 通常不需要解锁 Bootloader，操作简单。

  • 漏洞一旦被厂商修补，方法失效。

  • 现代 Android 安全机制日益完善，此类工具已很少见。

• 现状：主要存在于老旧设备或特定芯片平台。

获取 Root 权限后，如何安全、高效地管理授权是每个用户必须面对的问题。Root 管理不仅包括对应用程序授予或拒绝 Root 权限，还涉及权限日志、隐藏 Root、模块管理、更新维护等。现代 Root 方案（如 Magisk、KernelSU）已经将管理功能集成到配套的管理器应用中，而传统的 SuperSU 也有类似工具。

Root 方式工作原理详解

传统系统分区修改 Root（System-Mode Root）

System-Mode Root 是 Android 早期（约 Android 2.x 至 8.0 之前）最常见的获取 Root 权限方式。它的核心思想是直接修改/system分区，将su二进制文件和权限管理应用写入系统目录，从而在系统启动后为其他应用提供 Root 权限调用接口。随着 Android 安全机制的不断强化，这种方式已基本被淘汰，但理解其原理对于研究 Android 历史和安全演进仍有重要价值。

System-Mode Root 的本质是在只读的系统分区中植入提权程序。具体步骤如下：

1. 获得写入/system的权限

   • 通过解锁 Bootloader 刷入自定义 Recovery（如 CWM/TWRP），在 Recovery 模式下挂载/system为可读写。

   • 或者利用内核漏洞（如TowelRoot使用的 CVE-2014-3153、mtk-su等）在正常运行状态下临时获得 root 权限，然后重新挂载/system为可写。

2. 复制 Root 组件

   • 将su二进制文件（通常为静态编译，兼容多种架构）复制到/system/xbin/su或/system/bin/su，并设置 setuid 权限（chmod 6755），使普通应用可以调用它提升权限。

   • 安装权限管理应用（如 Superuser.apk 或 SuperSU.apk）到/system/app/或/system/priv-app/，作为系统应用，负责授权弹窗和日志记录。

   • 可能还会安装busybox（提供丰富的 Unix 命令）到/system/xbin/。

3. 修改系统属性或启动脚本（可选）

   • 某些实现会修改init.rc或添加启动脚本，确保su守护进程在开机时运行。

   • 或者修改ro.secure、ro.debuggable等系统属性，使系统默认处于宽松模式。

4. 重启生效

   • 系统重新启动后，/system中的su文件仍然存在，因为系统分区不会在正常重启时被擦除，从而实现“永久 Root”。

传统 System-Mode Root 是 Android 早期获取 Root 权限的经典方法，通过直接修改/system分区植入su二进制和管理应用来实现永久提权。它在 Android 2.x~6.x 时代发挥了重要作用，但随着验证启动、SELinux、动态分区等安全机制的普及，该方法已被淘汰，取而代之的是以 Magisk 为代表的 Systemless Root 方案。理解 System-Mode Root 的原理有助于深入认识 Android 安全演进史。

Systemless Root（无系统修改 Root）

Systemless Root 是一种不修改 Android 系统分区（/system）即可获取 Root 权限的技术方案。它通过修改启动镜像（boot.img）或利用其他非系统分区（如/data、/cache）来加载提权组件，从而保持系统分区的完整性和可验证性。

Systemless Root 的实现依赖于对启动流程的巧妙利用，主要分为以下几个步骤：

1. 修改 boot 镜像（ramdisk）

• Android 设备的启动过程由 bootloader 加载 boot.img，其中包含 Linux 内核和 ramdisk（初始根文件系统）。

• Systemless Root 工具（如 Magisk）会解包 boot.img，在 ramdisk 中添加自己的初始化脚本和二进制文件，然后重新打包。

• 关键修改：

  • 替换或修改init进程的执行流程，插入magiskinit等自定义初始化程序。

  • 在 ramdisk 中添加overlay挂载所需的文件（如 Magisk 的magisk二进制、策略文件等）。

2. 启动时注入

• 设备启动时，内核加载 ramdisk，执行被修改的init。

• magiskinit会在系统启动的早期阶段运行，完成以下任务：

  • 修补 SELinux 策略：临时放宽或注入自定义策略，允许 Magisk 服务运行。

  • 挂载 Magisk 镜像：将存储在/data分区中的 Magisk 文件（如magisk.img或模块文件）通过mount --bind或 overlayfs 挂载到系统目录（如/sbin、/system/bin），使su可用。

  • 启动 Magisk 守护进程：magiskd在后台运行，处理授权请求和模块管理。

3. 保持系统分区只读

• 所有 Root 相关的文件实际上存放在/data分区（用户数据分区），系统分区从未被写入。

• 因此 dm-verity 校验仍能通过，系统分区哈希保持不变。

4. 授权机制

• 当应用请求 Root 时，调用/sbin/su（或通过 Magisk 提供的su），该su与magiskd通信，弹出授权窗口。

• 授权策略存储在/data/adb/magisk.db数据库中，可持久化。

5. 模块系统（以 Magisk 为例）

• Magisk 模块是放置在/data/adb/modules/下的文件，启动时被 Magisk 挂载到系统中，实现系统级修改（如替换字体、添加特性），而无需真正修改系统分区。

• 这种“动态覆盖”机制既实现了定制，又不破坏系统完整性。

Systemless Root 是 Android Root 技术的革命性进步，它通过修改启动镜像而非系统分区，在获取 Root 权限的同时保持系统完整性，解决了 OTA 更新、应用检测和卸载困难等痛点。Magisk 作为其集大成者，不仅提供了稳定的 Root 方案，还构建了模块化生态。随着内核级方案（KernelSU、APatch）的出现，Systemless Root 的概念被进一步拓展到内核层，为用户提供了更多选择。对于现代 Android 设备，Systemless Root 是唯一推荐且可行的 Root 方式。

内核级 Root（Kernel-Assisted Root）

内核级 Root 是一种直接在 Android 内核空间中实现权限提升的 Root 方案。与传统的 System-Mode Root 和 Systemless Root（用户空间方案）不同，它通过修改内核代码或加载内核模块，在系统调用层面直接授予进程 Root 权限，从而绕过用户空间的su二进制文件和守护进程。代表性的实现有KernelSU和APatch。这种方案提供了极高的隐蔽性和控制力，成为高级用户和玩机爱好者的新选择。

内核级 Root 的核心在于让内核在特定时机（通常是进程执行时）判断是否授予 Root 权限。以最流行的 KernelSU 为例，其工作流程如下：

1. 加载内核模块或补丁

• KernelSU：通过刷入一个内核模块（.ko文件）或使用内置了 KernelSU 的内核。在 GKI 设备上，可以直接使用官方提供的通用模块，无需重新编译内核。

• APatch：直接对内核二进制文件打补丁（修改内核映像），在启动时加载补丁代码，不依赖模块加载机制。

• 加载过程发生在内核启动早期，早于任何用户空间程序。

2. 挂钩系统调用

• KernelSU 等方案会修改内核的execve系统调用（或execveat），该调用负责执行新的程序。

• 修改后的execve会检查即将运行的程序的调用者 UID 或目标 UID：

  • 如果调用者（或目标）的 UID 在授权白名单中，且目标程序请求 Root 权限，则内核直接赋予其CAP_SYS_ADMIN等 Capabilities 或将其 UID/GID 设置为 0（root）。

  • 如果未授权，则正常执行，不做任何更改。

• 这一过程完全在内核态完成，用户空间没有任何su文件或守护进程参与。

3. 授权管理

• 虽然权限授予在内核完成，但用户仍需要一个管理界面来决定哪些应用可以获取 Root。这通过一个配套的管理器应用（如 KernelSU Manager）实现。

• 管理器通过自定义的内核接口（如/proc文件系统、Netlink 套接字或 sysfs）与内核通信，维护授权列表。

• 当应用请求 Root 时，内核检查该 UID 是否已被授权；如果是，则直接提升权限；否则拒绝（或通知管理器弹窗，取决于配置）。

4. 模块系统

• KernelSU 和 APatch 也支持模块系统，模块文件存放在/data分区，启动时由内核或初始化脚本挂载，实现类似 Magisk 的功能（替换文件、注入库等）。

• 部分模块利用内核态的能力实现更底层的修改，例如修改 SELinux 策略、隐藏进程等。

5. SELinux 处理

• 内核级 Root 仍然需要处理 SELinux 的限制。通常通过临时注入 SELinux 策略或让 root 进程运行在宽松域中来实现完整权限。

• 由于修改发生在内核，对 SELinux 的处理更为直接，也更具隐蔽性。

内核级 Root 代表了 Android Root 技术的最高水平，它将权限提升直接嵌入内核，提供了无与伦比的隐蔽性和控制力。KernelSU和APatch是当前的代表，前者依托 GKI 生态，后者则覆盖更广泛的内核版本。尽管安装和维护门槛较高，但对于追求极致隐蔽、需要绕过严格检测的高级用户来说，内核级 Root 是最佳选择。随着 Android 生态的演进，内核级 Root 有望成为玩机圈的新标准。

漏洞利用 Root（Exploit-Based Root）

漏洞利用 Root 是一种通过利用 Android 系统或内核中存在的安全漏洞来获取 Root 权限的方法。它不需要解锁 Bootloader，也不需要修改系统分区（至少在初始阶段），通常只需在设备上运行一个特定的应用程序（APK）或脚本即可完成提权。

漏洞利用 Root 的通用流程如下：

漏洞利用 Root 的通用流程如下：

1. 漏洞触发

   • 利用内核漏洞（如futex系统调用竞争条件）、驱动漏洞（如 GPU、Wi-Fi 驱动）、系统服务漏洞（如vold、mediaserver）等，在系统进程中执行恶意代码。

   • 常见漏洞类型：缓冲区溢出、释放后使用（UAF）、权限检查缺失、竞争条件等。

2. 权限提升

   • 漏洞代码运行在具有高权限的进程上下文（如system、root或内核态），通过修改进程凭证（cred结构体）将当前进程的 UID/GID 改为 0，或直接调用commit_creds(prepare_kernel_cred(0))获取 root 权限。

3. 安装 Root 组件（可选）

   • 获得 root 权限后，工具通常会将su二进制文件、busybox和授权管理应用（如 Superuser、SuperSU）安装到/system分区，并设置 setuid 权限，以实现永久 Root。

   • 如果漏洞只允许临时提权且无法写入系统分区（例如系统分区为只读或受 dm-verity 保护），则 Root 权限在重启后消失。

4. 授权管理

   • 安装的授权管理应用负责后续的 Root 请求弹窗和日志记录，与 System-Mode Root 或 Systemless Root 中的管理类似。

它利用系统或内核缺陷，无需解锁 Bootloader 即可获得 Root 权限。TowelRoot、Framaroot、KingRoot 等工具曾是无数用户的“神器”。然而，随着 Android 安全机制的日益完善，这类方法已完全退出历史舞台。今天，想要 Root 的用户必须解锁 Bootloader 并采用 Magisk、KernelSU 等现代方案。漏洞利用 Root 的兴衰，也反映了 Android 平台从开放到逐步收紧的安全演进历程。

为帮助读者更直观地把握四种 Root 方案的差异，下表从原理、系统分区影响、OTA 兼容性、隐蔽性、适用设备、维护难度等维度进行横向对比：

总结与建议

刷机与 Root 的本质，是在安卓系统的安全边界与用户自由度之间做出权衡。理解权限机制、分区结构和各类 Root 方案的原理，是安全进行深度定制的前提。以下从核心要点、风险提示和学习资源三个维度进行总结。

核心要点

• 权限分层：软件权限、用户权限与超级用户权限（Root）逐级递进，Root 拥有最高控制力，也意味着最高风险。
• 分区认知：传统分区（boot、system、vendor、userdata 等）与 Android 10 之后的动态分区（super）结构不同，刷机前务必确认设备对应的分区方案。
• Root 方案演进：System-Mode Root 已基本淘汰；Systemless Root（Magisk）是当前主流推荐；内核级 Root（KernelSU、APatch）与漏洞利用 Root 各有适用场景。
• 系统完整性：现代 Root 方案通过修改 boot 镜像或内核而非系统分区，保持 dm-verity 校验通过，从而兼顾 OTA 更新与定制需求。

风险提示

• 保修失效：解锁 Bootloader 或刷入非官方固件通常会使设备失去官方保修资格。
• 数据丢失：刷机、恢复出厂设置或误操作分区可能导致数据清空，操作前务必完整备份。
• 变砖风险：错误刷入不匹配的分区镜像或中断刷机流程，可能导致设备无法开机，需借助 Recovery 或底层工具修复。
• 安全威胁：Root 权限一旦被恶意应用获取，可读取敏感数据、篡改系统，应谨慎授权并定期检查权限日志。
• 功能异常：部分银行、支付类应用会检测 Root 并拒绝运行，隐藏 Root 也并非对所有检测都有效。

为了让新手读者更直观地理解上述风险，下面针对每类风险补充一个真实或典型的案例，并给出对应的预防措施与应急恢复建议。

1. 保修失效

典型案例：某用户新购一台国行旗舰手机，为体验第三方 ROM 解锁了 Bootloader 并刷入 Magisk。数月后手机主板出现故障送修，售后检测到 Bootloader 已解锁，直接以「非官方系统改动」为由拒绝保修，用户只能自费维修。

• 预防措施：刷机前确认设备是否仍在保修期内；了解厂商对解锁 Bootloader 的保修政策；若需保修，可先尝试官方渠道恢复原厂固件并重新上锁（部分机型支持）。
• 应急恢复建议：保留原厂固件与官方刷机工具，必要时刷回官方系统并重新锁定 Bootloader，再送修。

2. 数据丢失

典型案例：某用户刷入第三方 ROM 前未备份，刷机过程中误选了「清除 data 分区」，导致相册中数年的照片、聊天记录和各类应用数据全部清空，且未开启云同步，损失无法挽回。

• 预防措施：刷机前务必使用官方备份工具、云服务或第三方工具（如 Titanium Backup、Swift Backup）完整备份应用数据、照片与联系人；重要资料可额外拷贝到电脑或移动硬盘。
• 应急恢复建议：若误清数据，立即停止写入新数据，尝试用数据恢复工具扫描 userdata 分区；平时养成定期备份习惯，可显著降低损失。

3. 变砖风险

典型案例：某用户为追求新版内核，刷入了与机型不匹配的 boot 镜像，重启后设备卡在开机 Logo 无法进入系统，进入 Recovery 也无法正常挂载分区，最终只能借助厂商底层工具（如 EDL、Odin）重新刷入官方固件才救回。

• 预防措施：刷机前核对固件、内核与机型的精确匹配关系；优先使用官方或社区验证过的镜像；刷机过程中保持电量充足、避免中断。
• 应急恢复建议：先尝试进入 Recovery 清除缓存或恢复出厂；若无效，使用厂商底层刷机工具（如小米 EDL、三星 Odin）刷回官方完整包；严重时需联系售后或专业维修。

4. 安全威胁

典型案例：某用户 Root 后为图方便，将 Root 权限默认授予了一款来路不明的「系统清理」应用。该应用利用 Root 权限在后台静默读取通讯录、短信与银行类应用数据，并私自安装推广软件，用户发现时隐私已大量泄露。

• 预防措施：仅从可信来源安装应用；Root 授权遵循「最小化」原则，按需临时授予，不随意默认授权；定期查看权限日志，撤销可疑应用的 Root 权限。
• 应急恢复建议：立即在 Root 管理器中撤销并删除可疑应用，清除其数据；修改相关账号密码；必要时恢复出厂设置并重新评估 Root 方案。

5. 功能异常

典型案例：某用户 Root 后开启某银行 App，应用检测到 Root 环境后直接闪退并提示「设备不受信任」，无法进行转账与支付；即使用户尝试隐藏 Root，部分风控严格的 App 仍能识别并拒绝服务。

• 预防措施：了解常用银行、支付类应用对 Root 的检测策略；可尝试使用 MagiskHide、Zygisk 或 Shamiko 等隐藏方案，但需明白并非对所有检测都有效。
• 应急恢复建议：若某应用必须使用且无法绕过检测，可临时卸载 Root 或刷回官方系统；日常可将 Root 设备与主力支付设备分开使用，降低影响。

推荐学习资源

• 官方文档：Android 开发者官网的「分区」「OTA 更新」「验证启动」等章节，是理解系统机制的第一手资料。
• 开源社区：Magisk、KernelSU、APatch 的官方仓库与文档，涵盖安装、模块开发与常见问题排查。
• 刷机论坛：XDA Developers 等社区汇聚了大量设备专属的刷机教程与经验分享，可按机型检索。
• 实践建议：先在备用设备上练习，遵循「先备份、再解锁、后刷入」的顺序，逐步积累经验。