ADB与Fastboot本质区别：协议层、驱动层与权限模型解析

简介：本资源为Android开发与系统调试必备的adb与fastboot命令行工具集，面向Android开发者、ROM定制爱好者及移动终端运维人员，解决设备连接调试、固件刷写、日志分析与底层故障修复等核心问题。压缩包共877个文件，5.05MB，涵盖333个Python脚本（用于自动化调试与性能采集）、87个CSS/HTML/JS前端资源（支撑配套Web界面或文档渲染）、83个编译产物（如.out/.pyc）及10余个Windows可执行文件（含adb.exe、fastboot.exe），另有大量ATrace性能追踪相关数据文件与Chrome集成调试模块，体现其深度适配Android系统级性能分析场景。已有3917人学习下载，资源结构完整、即开即用，无需额外配置SDK环境，特别适合快速部署调试环境、复现系统启动流程、开展应用冷启动性能剖析及Bootloader解锁后的分区操作实践。

1. ADB与Fastboot不是“一个工具”，而是两套底层通信协议的命令行实现

很多人第一次接触“adb fastboot 工具”这个说法时，下意识会把它当成一个叫“ADB Fastboot”的单一软件——就像微信、QQ那样点开就能用。但事实恰恰相反：ADB（Android Debug Bridge）和Fastboot是两套完全独立、互不兼容、运行在不同系统层级的通信机制，它们共用同一个可执行文件名（adb.exe / adb），却通过完全不同的握手流程、驱动栈和内核态支持来工作。这个根本性误解，正是后续90%以上“设备找不到”“命令无效”“授权失败”问题的源头。

我刚入行做安卓固件适配时，就栽在这上面。当时给一台老款华为Mate 9刷第三方Recovery，反复执行adb reboot bootloader后手机进的是Fastboot界面，但一敲fastboot devices，终端永远返回空行。折腾三小时，重装驱动、换USB口、换线、换电脑……最后发现，问题根本不在驱动，而在于：Windows系统里只装了ADB Interface驱动，却没装Fastboot USB Device驱动——这两者在设备管理器中显示为完全不同的硬件ID，需要分别识别、分别安装。

为什么必须分清？因为它们的工作场景天差地别：

• ADB运行在Android系统已启动的状态下，依赖adbd守护进程（通常位于/system/bin/adbd），走的是USB Mass Storage或MTP协议之上的自定义Socket通道，权限模型基于Linux UID/GID + Android SELinux策略；
• Fastboot则运行在Bootloader层（高通叫LK，联发科叫Preloader，三星叫Download Mode），此时Android内核尚未加载，adbd根本不存在，通信靠Bootloader内置的Fastboot协议解析器，所有操作都绕过系统权限管控，直接读写分区表、烧录镜像、解锁BL。

提示：你可以把ADB理解成“安卓系统的远程控制台”——你得先开机、解锁、允许调试，它才给你开门；而Fastboot则是“主板BIOS级的维修接口”——只要设备通电、进入特定模式，它就随时待命，不认密码、不看系统状态。两者就像家里的智能音箱（ADB）和电闸总开关（Fastboot），功能完全不同，不能混用。

这种差异直接决定了它们的命令集、错误码、超时机制和调试路径。比如adb shell失败，你得查adbd是否运行、SELinux是否拒绝、USB调试是否开启；而fastboot devices失败，你得查Bootloader是否被锁、USB描述符是否被厂商屏蔽、Windows是否识别为“Android Bootloader Interface”而非“Unknown Device”。

更关键的是，绝大多数所谓“ADB Fastboot工具包”其实只是把adb.exe、fastboot.exe、AdbWinApi.dll、AdbWinUsbApi.dll这四个文件打包压缩——它们本身不提供任何新功能，只是官方SDK的精简搬运工。真正决定你能否用起来的，从来不是下载哪个“绿色版”，而是你是否理解这两套协议背后的硬件握手逻辑、驱动加载路径和系统权限边界。

这也是为什么网上充斥着“fastboot找不到设备”“adb unauthorized”“小米fastboot线刷失败”等高频问题——大家在用同一套命令，却没意识到自己正在切换两个完全不同的世界。接下来，我们就从最底层的USB协议握手开始，一层层剥开它们的真实面目。

2. USB握手本质：ADB与Fastboot如何让Windows“认出”你的手机

当你把手机用USB线连到电脑，Windows不是靠“看图标”或“读品牌名”来识别设备的，而是严格遵循USB协议规范，通过一系列标准化的数据包交换，获取设备的Vendor ID（VID）和Product ID（PID），再匹配本地.inf驱动文件中的硬件ID列表。这个过程，就是“握手”。而ADB与Fastboot的握手方式，截然不同。

2.1 ADB模式下的USB握手链路

当手机处于“开发者选项→USB调试开启”状态，并连接电脑时，其USB控制器会向PC发送如下描述符：

• bDeviceClass = 0xFF（Vendor-specific class）
• idVendor = 0x0502（华硕）、0x05c6（高通）、0x18d1（Google）、0x2717（小米）等
• idProduct = 0x9001（ADB Interface通用PID）或厂商定制PID（如小米为0x900e）

Windows收到后，会在注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{36fc9e60-c465-11cf-8056-444553540000}下查找匹配的.inf文件（如android_winusb.inf），加载WdfCoInstaller01011.dll并调用AdbWinUsbApi.dll完成端点映射。此时设备管理器中显示为：

Android Device → Android ADB Interface

注意：这里的“Android ADB Interface”是微软WHQL认证过的标准设备类，驱动签名有效，无需手动禁用驱动签名强制。

2.2 Fastboot模式下的USB握手链路

当你执行adb reboot bootloader或同时按住音量减+电源键强制进入Bootloader时，手机的SoC会关闭Android系统，启动Bootloader固件。此时USB控制器重新初始化，发送全新描述符：

• bDeviceClass = 0xFF（依然是Vendor-specific）
• idVendor = 同ADB模式（如0x18d1）
• idProduct = 0x0bb4（Google Fastboot通用PID）或厂商定制PID（如华为为0x0ff9，vivo为0x500a）

关键区别来了：Windows默认没有为这些Fastboot PID预装驱动！它只会识别为：

Other devices → Android Bootloader Interface（带黄色感叹号）

或者更糟——直接显示为“Unknown Device”。因为微软inf库中只收录了极少数厂商的Fastboot PID，而国产手机大多使用私有PID，必须手动注入驱动映射。

注意：很多教程让你“右键更新驱动→浏览计算机→选android_winusb.inf”，这步之所以常失败，是因为inf文件里默认只包含0x0bb4、0x0bb5等Google PID，而你的小米可能是0x9008，华为是0x0ff9，vivo是0x500a——这些PID根本不在inf的[Google.NTamd64]段落里。你必须手动编辑inf，在[Google.NTamd64]下方添加一行：
%SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_9008
然后保存，再右键更新驱动。否则永远“找不到设备”。

2.3 实测验证：用USBlyzer抓包看真实握手差异

我用USBlyzer（一款USB协议分析工具）实测过小米12的两种模式：

• ADB模式握手：PC发出GET_DESCRIPTOR请求，手机返回bcdUSB=2.00,bDeviceClass=FFh,idVendor=2717h,idProduct=900eh，随后建立Bulk IN/OUT端点（EP01/EP02）用于ADB数据传输；
• Fastboot模式握手：PC同样发GET_DESCRIPTOR，手机返回bcdUSB=2.00,bDeviceClass=FFh,idVendor=2717h,idProduct=9008h，但端点配置完全不同——只有Control Endpoint（EP00），所有命令都走SETUP包，数据阶段用IN/OUT令牌传输二进制payload。

这意味着：即使你用同一根USB线、同一个USB口、同一台电脑，ADB能通≠Fastboot能通。因为它们是两套独立的USB设备实例，共享物理接口，但逻辑上互不感知。这也是为什么有人“adb devices能看到，fastboot devices看不到”的根本原因——驱动只装了一半。

2.4 驱动安装的终极方案：Zadig + WinUSB替代方案

对于那些inf文件改了还是不行的顽固设备（尤其是Win10/Win11新系统），我推荐用Zadig工具强制替换驱动：

1. 下载Zadig（官网zadig.akeo.ie），以管理员身份运行；
2. Options → List All Devices，勾选“Show all Devices”；
3. 在下拉框中选择你的“Android Bootloader Interface”设备；
4. Driver dropdown选“WinUSB (v6.1 or later)”；
5. Click “Replace Driver”。

为什么WinUSB可行？因为它绕过了传统.inf匹配机制，直接将设备绑定到Windows原生WinUSB.sys驱动，该驱动支持任意VID/PID组合，且无需数字签名。实测在Win11 22H2上，Zadig替换后fastboot devices秒回设备序列号，比手动inf编辑成功率高90%。

提示：Zadig替换后，设备管理器中会显示为“WinUSB Device”，而不是“Android Bootloader Interface”。这是正常现象，说明底层通信已打通。但要注意——Zadig只解决“识别”，不解决“解锁”。如果Bootloader被锁，fastboot oem unlock仍会返回FAILED (remote: 'Device is locked')，这是硬件级保护，与驱动无关。

3. 命令执行逻辑：为什么adb shell报错和fastboot flash失败的根本原因完全不同

很多人把adb shell和fastboot flash boot.img当成同类操作——都是“往手机发命令”。但它们的执行路径、失败节点和调试方法，完全是两条平行线。搞不清这点，排查就会南辕北辙。

3.1adb shell的完整执行链路与失败定位点

当你在CMD中输入adb shell，背后发生的是一个跨三层的复杂调用：

CMD → adb.exe → TCP Socket → adbd守护进程 → Linux Shell

具体步骤：

1. adb.exe先向adb server（默认监听localhost:5037）发送host:transport-serial请求，确认目标设备在线；
2. server转发shell:命令到设备端adbd进程；
3. adbd检查/dev/adb_enable是否为1，读取ro.adb.secure属性值；
4. 若ro.adb.secure=1，则要求设备端弹出RSA密钥确认对话框；
5. 用户点击“允许”后，adbd生成临时密钥对，建立加密Socket通道；
6. 最终调用/system/bin/sh启动交互式Shell。

所以adb shell失败，可能卡在任一环节：

• Step 1失败：adb server未启动 → 执行adb kill-server && adb start-server；
• Step 2失败：adbd未运行 →adb shell getprop | grep adbd看是否为adbd，或adb root尝试提权；
• Step 3失败：ro.adb.secure=1但未授权 → 手机弹窗点“允许”，或adb usb重启ADB；
• Step 4失败：/data/misc/adb/adb_keys被清空 → 电脑~/.android/adbkey.pub需重新配对；
• Step 5失败：SELinux阻止adbd执行sh→adb shell su -c "setenforce 0"临时关闭（仅调试用）。

实操心得：遇到error: device not found，第一反应不该是重插线，而是先adb devices看设备是否在列表里。如果列表为空，说明adb server根本没连上设备，此时重插线才有意义；如果列表有设备但adb shell报错，则问题一定在设备端adbd或权限层，重插线毫无作用。

3.2fastboot flash的执行链路与典型故障树

fastboot flash boot boot.img的执行路径短得多，但也更“硬核”：

CMD → fastboot.exe → USB Control Transfer → Bootloader → 分区写入

关键步骤：

1. fastboot.exe向设备发送FB_COMMAND包，内容为flash:boot；
2. Bootloader解析命令，校验boot.img头部magic（ANDROID!）和size；
3. 检查当前分区是否可写（fastboot getvar is-unlocked返回yes）；
4. 将boot.img数据分块（每块64KB）通过DOWNLOAD指令写入RAM缓冲区；
5. 调用write函数将缓冲区数据刷入/dev/block/bootdevice/by-name/boot。

因此fastboot flash失败，常见原因有：

• Command rejected：Bootloader被锁，is-unlocked返回no → 必须先fastboot oem unlock（部分厂商需申请解锁码）；
• Invalid sparse file：boot.img不是标准Android格式，magic不对 → 用file boot.img检查是否含ANDROID!头；
• Flashing not allowed：厂商在Bootloader中禁用了flash指令（如华为、OPPO）→ 只能刷官方固件包；
• Verify failed：boot.img校验失败，可能是下载损坏或被篡改 → 用sha256sum比对原始镜像；
• No such partition：分区名错误，如小米应为bootimg而非boot→fastboot getvar all查真实分区名。

注意：fastboot flash失败时，fastboot命令本身不会报错，而是返回FAILED (remote: '...')。这个括号里的字符串是Bootloader固件直接返回的错误信息，每个芯片平台返回的错误码含义都不同。比如高通平台FAILED (remote: 'Partition table not found')意味着分区表损坏，而联发科平台同字符串可能表示USB连接不稳定。必须结合芯片型号查对应文档。

3.3 交叉验证法：用adb和fastboot互相诊断

最高效的排错方式，是让两个工具互相印证：

• 如果adb devices能看到设备，但fastboot devices看不到 → 100%是Fastboot驱动问题（见2.2节）；
• 如果fastboot devices能看到设备，但adb devices看不到 → 可能是adbd被停用（adb disable-adb）、SELinux阻止或USB调试关闭；
• 如果两者都看不到，但设备管理器有“Android”字样 → 检查USB线是否支持数据传输（很多充电线只有VCC/GND，无D+/D-）；
• 如果设备管理器显示“Unknown Device”，且Zadig也无法识别 → 手机USB接口物理损坏，或Bootloader固件异常。

我曾遇到一台老款创维电视，adb devices始终为空。用USBlyzer抓包发现，它在ADB模式下只发送了GET_DESCRIPTOR，却不响应后续SET_CONFIGURATION请求——这是Bootloader固件bug，导致USB枚举失败。最终解决方案是：用另一台已root的安卓手机，通过adb shell input keyevent 26模拟电源键，强制其进入Fastboot，再用fastboot flash recovery刷入第三方Recovery，从而绕过ADB依赖。

4. 环境配置避坑指南：为什么你装了SDK却还是“不是内部或外部命令”

网上90%的“adb不是内部或外部命令”问题，根源不在下载链接，而在环境变量配置的三个致命细节。我见过太多人反复卸载重装Android SDK，却始终卡在这一步。

4.1 PATH变量的“路径拼接陷阱”

Android SDK默认安装路径为：

C:\Users\<用户名>\AppData\Local\Android\Sdk\platform-tools\

其中platform-tools目录下才有adb.exe和fastboot.exe。但很多人复制路径时，习惯性删掉末尾的\，变成：

C:\Users\<用户名>\AppData\Local\Android\Sdk\platform-tools

然后粘贴到PATH里。问题来了：Windows的PATH解析器，会把末尾无\的路径，与后续命令名强行拼接。当你输入adb，系统实际搜索的是：

C:\Users\<用户名>\AppData\Local\Android\Sdk\platform-toolsadb.exe

注意中间没有\！自然找不到文件。

正确做法：

• 复制路径时，务必保留末尾反斜杠：C:\Users\<用户名>\AppData\Local\Android\Sdk\platform-tools\；
• 或者在PATH编辑框中，手动在路径末尾加\；
• 更稳妥的方式：用CMD执行set PATH=%PATH%;C:\Users\<用户名>\AppData\Local\Android\Sdk\platform-tools\，再测试adb version。

4.2 用户变量 vs 系统变量：权限继承的隐形墙

Windows有“用户环境变量”和“系统环境变量”两套PATH。很多教程让你“编辑系统变量”，但如果你是普通用户（非Administrator），修改系统变量需要UAC提权，且新打开的CMD窗口可能无法继承变更。

实测发现：

• 用setx PATH "%PATH%;新路径"命令修改，只对新启动的CMD生效，当前窗口不变；
• 修改用户变量PATH，对当前用户所有新进程生效；
• 修改系统变量PATH，对所有用户生效，但需管理员权限。

我的建议是：优先修改用户变量PATH。步骤：

1. Win+R →sysdm.cpl→ “高级”选项卡 → “环境变量”；
2. 在“用户变量”区域，找到Path，双击编辑；
3. 点“新建”，粘贴C:\Users\<用户名>\AppData\Local\Android\Sdk\platform-tools\；
4. 确定保存，关闭所有CMD窗口，重新打开一个，再执行adb version。

提示：adb version返回版本号，只能证明PATH配置成功；要验证ADB真正可用，必须执行adb devices并看到设备列表。因为adb version只调用本地exe，而adb devices需要与server通信。

4.3 权限冲突：杀毒软件对adb.exe的静默拦截

某些国产杀软（如某360、某腾讯）会将adb.exe标记为“高危工具”，在后台静默拦截其网络连接或进程创建。表现是：adb version能运行，但adb devices永远卡住，任务管理器里看不到adb.exe进程。

检测方法：

• 任务管理器 → “详细信息”页签 → 查找adb.exe进程；
• 若无进程，但CMD里adb devices光标一直闪烁 → 极可能是杀软拦截。

解决方案：

• 临时关闭杀软实时防护；
• 或将adb.exe、fastboot.exe所在目录加入杀软白名单；
• 更彻底的方法：用Process Monitor（Sysinternals工具）过滤adb.exe，看其CreateProcess或ConnectNamedPipe操作是否被ACCESS DENIED。

4.4 替代方案：免配置的Portable ADB

如果你只是偶尔用ADB，不想折腾环境变量，我推荐Portable ADB方案：

1. 下载platform-tools-latest-windows.zip（官网developer.android.com）；
2. 解压到任意目录，如D:\tools\adb\；
3. 在该目录下新建文本文件，命名为adb.bat，内容为：

@echo off cd /d "D:\tools\adb" adb %* pause

4. 双击adb.bat，即可直接运行ADB命令。

这个方案的优势是：

• 完全隔离，不污染系统PATH；
• 可为不同项目建多个ADB目录（如adb-mi、adb-huawei），避免版本冲突；
• pause命令让窗口不闪退，方便查看错误信息。

实操心得：我在给客户做现场支持时，从不装SDK，就用Portable ADB。U盘里存着adb.bat和最新platform-tools，插上电脑双击即用，客户看着都惊讶——原来ADB还能这么轻量。

5. 高阶实战：从提取boot.img到重打包，一次搞懂Android启动镜像结构

很多进阶需求，如修改开机Logo、绕过厂商启动屏、patch内核模块，都绕不开boot.img操作。但网上教程要么只教adb pull /dev/block/bootdevice/by-name/boot boot.img（这根本不行！），要么直接甩出一堆mkbootimg参数让人懵圈。我们从原理出发，一步步拆解。

5.1 为什么不能直接adb pullboot分区？

/dev/block/bootdevice/by-name/boot是一个块设备文件（block device），不是普通文件。adb pull只能传输普通文件（regular file），对块设备会返回Permission denied或空文件。正确方法是：

adb shell "dd if=/dev/block/bootdevice/by-name/boot of=/sdcard/boot.img" adb pull /sdcard/boot.img

dd命令将块设备内容逐扇区复制到SD卡上的普通文件，再用adb pull拉取。

但注意：dd需要root权限。如果设备未root，adb shell dd会失败。此时唯一办法是：在Fastboot模式下用fastboot flash配合fastboot boot临时启动，但这无法提取原镜像。所以，提取boot.img的前提，是设备已root或Bootloader已解锁。

5.2boot.img的四层结构解析

一个标准boot.img不是简单二进制，而是分层封装：

用file boot.img可初步判断：

boot.img: Android bootimg, kernel (0x8000), ramdisk (0x1000000), page size 2048, os version 12.0.0

这告诉你：kernel起始地址0x8000，ramdisk起始0x1000000，页大小2048字节。

5.3 重打包boot.img的完整流程（以修改init.rc为例）

假设你想在init.rc里加一行setprop sys.boot.reason user，步骤如下：

1. 解包：

# 提取header信息 ./mkbootimg --dump boot.img > header.txt # 解包kernel和ramdisk ./mkbootimg --unpack boot.img # 生成kernel, ramdisk.cgz, second, dtb等文件

2. 修改ramdisk：

mkdir ramdisk && cd ramdisk gunzip -c ../ramdisk.cgz | cpio -i # 编辑init.rc vi init.rc # 重新打包 find . | cpio -H newc -o | gzip > ../new-ramdisk.cgz

3. 重打包：

# 使用原header参数重建 ./mkbootimg \ --kernel kernel \ --ramdisk new-ramdisk.cgz \ --base 0x80000000 \ --pagesize 2048 \ --kernel_offset 0x00008000 \ --ramdisk_offset 0x01000000 \ --tags_offset 0x00000100 \ --os_version 12.0.0 \ --os_patch_level 2022-01-01 \ --output new-boot.img

4. 刷入验证：

fastboot flash boot new-boot.img fastboot reboot

关键细节：--base参数必须与原镜像一致，否则内核加载地址错位会导致黑屏。--os_version和--os_patch_level需与设备getprop ro.build.version.release和ro.build.version.security_patch匹配，否则部分厂商Bootloader会拒绝刷入。

5.4 实战避坑：小米、华为、vivo的boot.img特殊处理

不同厂商对boot.img做了定制，直接套用标准流程会失败：

• 小米：使用lk（Little Kernel）作为Bootloader，boot.img中second段存储lk代码，修改init.rc后必须用miboot工具重签名，否则fastboot flash返回FAILED (remote: 'Signature verify fail')；
• 华为：boot.img头部含HUAWEI魔数，且ramdisk为lzma压缩，需用lzma -d解压；
• vivo：boot.img分boot_a和boot_b两个分区，刷入时必须指定fastboot flash boot_a new-boot.img，否则默认刷boot_b，重启后仍用旧镜像。

我的经验是：先fastboot getvar all查厂商信息，再针对性搜索<厂商> boot img format。比如搜“vivo boot img lz4”，就能找到其ramdisk实际是lz4压缩，而非标准gzip。

6. 安全边界提醒：ADB与Fastboot的权限天花板在哪里

最后必须强调：ADB和Fastboot不是万能钥匙。它们的能力边界，由硬件设计、Bootloader安全策略和Android版本共同划定。忽视这点，轻则操作失败，重则变砖。

6.1 ADB的权限天花板：SELinux与ro.secure

从Android 4.3开始，adbd进程默认运行在u:r:adbd:s0SELinux域下，受/sepolicy规则约束。即使root，adb shell也无法执行某些操作：

• mount -o remount,rw /system→ SELinux拒绝mounton权限；
• kill -9 $(pidof zygote)→adbd无signal权限；
• dd if=/dev/block/mmcblk0 of=/sdcard/dump.img→adbd无block_device读取权限。

解决方案只有两个：

• 临时关闭SELinux：adb shell su -c "setenforce 0"（重启后恢复）；
• 永久修改sepolicy（需重新编译内核，不推荐）。

注意：“adb root”命令在Android 7.0+已废弃，ro.secure=1时adbd永远以shell用户运行，su命令本身也受SELinux限制。

6.2 Fastboot的硬件级锁：OEM Unlock与Secure Boot

fastboot oem unlock不是软件开关，而是触发SoC的eFuse熔断。高通平台一旦执行，eFuse永久置1，无法恢复；联发科平台则写入preloader分区标志位。这意味着：

• 解锁后，Bootloader会显示“UNLOCKED”字样，且fastboot getvar is-unlocked返回yes；
• 但部分厂商（如华为、OPPO）在Bootloader中硬编码了flash指令禁用，即使解锁，fastboot flash boot仍返回FAILED (remote: 'Flashing is not allowed')；
• 更重要的是，解锁后首次启动，系统会自动Factory Reset，清除所有用户数据——这是硬件强制行为，无法绕过。

6.3 真实风险案例：一次fastboot flash引发的变砖

去年帮朋友救一台红米Note 8，他想刷LineageOS，但没看清教程，执行了：

fastboot flash system system.img

结果system.img是针对lavender（Redmi Note 7）的，而他的设备是ginkgo（Note 8），分区布局不同。刷入后，fastboot getvar product仍显示ginkgo，但fastboot boot boot.img黑屏。

原因：system.img写入了错误的super分区，破坏了动态分区表（Dynamic Partition Table），导致init无法挂载/system。最终解决方案是：

1. 用fastboot getvar all确认current-slot为_a；
2. 下载官方ginkgo固件，提取super_empty.img；
3. fastboot flash super super_empty.img重置分区表；
4. 再刷入正确的system_other.img。

这个案例说明：Fastboot操作没有“撤销键”。每一次flash，都是对NAND Flash的物理写入，错误镜像会直接覆盖关键元数据。所以，操作前必须100%确认设备代号、镜像匹配度、分区名，宁可多查三次，也不盲目执行。

我在实际工作中，所有Fastboot操作都遵循“三查一备份”原则：

• 查fastboot getvar product确认设备代号；
• 查fastboot getvar variant确认SoC型号；
• 查fastboot getvar all确认解锁状态和分区布局；
• 备份boot、recovery、vbmeta三个关键分区。

这看似繁琐，但比起花三天救一台变砖机，多花三分钟绝对值得。技术可以学，时间无法倒流。

本文还有配套的精品资源，点击获取