1. 离线设备到底卡在哪：从一次调试说起
做移动端调试的人，几乎都遇到过这样的场景：手头一台测试机反复插拔，或者无线调试连了一半断掉，再执行adb devices的时候，列表里赫然躺着一行offline状态的设备。它既不能装应用，也不能抓日志，甚至连adb shell都进不去，但就是赖在设备列表里不走。更烦的是，有时候同一台设备会同时出现device和offline两条记录，端口号还不一样，让人分不清到底该操作哪一个。
这个项目标题说的就是这件事：adb 删除 offline 设备。听起来像个小操作，但真到动手的时候，很多人会发现adb disconnect报错、adb kill-server之后设备又回来了、重启电脑才恢复正常。它解决的核心问题是：当 ADB 服务端维护的设备连接状态与实际物理连接不一致时，如何把那些僵死的、无法通信的条目从设备列表里干净地清掉，让调试环境恢复到可用状态。
适合看这篇内容的人包括：日常用真机调试的 Android 开发者、做自动化测试需要批量管理设备的测试工程师、玩机折腾刷机的爱好者，以及任何被offline状态卡过进度的人。不管你是刚装完 ADB 的新手，还是用了好几年但一直靠“重启大法”解决问题的老手，下面这套从原理到实操的梳理都能直接拿去用。我会把 ADB 的设备状态机讲清楚，把几种删除方式的适用场景和坑点摆出来，再给一份可以照着敲的命令清单。
2. 先搞懂 ADB 的设备状态机，别急着敲命令
2.1 offline 不是“设备关机了”，而是握手没完成
很多人第一次看到offline会以为是手机没电或者关机了，其实不是。ADB 的架构是典型的 C/S 模式：你电脑上跑的是ADB Server（后台服务进程），设备上跑的是adbd（ADB Daemon）。两者之间通过 USB 或 TCP 建立连接，连接建立后会有一个版本协商和认证握手的过程。
adb devices输出的状态主要有这么几种：
| 状态 | 含义 | 能否执行 adb 命令 |
|---|---|---|
device | 握手完成，连接正常 | 可以 |
offline | 连接建立了，但握手/认证没走完 | 不可以 |
unauthorized | 设备端未授权这台电脑的调试密钥 | 不可以，需在设备上点允许 |
no permissions | 电脑端没有访问该 USB 设备的权限 | 不可以，需配 udev 规则 |
bootloader | 设备处于 fastboot/bootloader 模式 | 需用 fastboot 命令 |
所以offline的本质是：ADB Server 知道有这么个设备（或者曾经知道），但没法跟它正常对话。常见诱因有几个：USB 线接触不良导致连接中途断开、设备端 adbd 进程崩溃或卡死、ADB Server 与 adbd 的协议版本不匹配、无线调试时网络抖动导致 TCP 连接半开、以及同一台设备被多个 ADB 实例或端口重复注册。
2.2 为什么“删不掉”：ADB 的设备列表是服务端内存态
关键点来了：adb devices列出来的东西，是ADB Server 进程内存里维护的一张设备表，不是从系统设备管理器实时读出来的。这就解释了为什么你拔了线，offline条目还在——因为 Server 还没收到断开事件，或者收到了但没清理干净。
这也决定了删除思路分两个层次：
- 软删除：让 Server 主动断开某个连接，比如
adb disconnect，适用于 TCP 连接。 - 硬重置：直接干掉 Server 进程让它重建设备表，比如
adb kill-server，适用于 USB 连接或状态彻底错乱的情况。
理解了这一层，你就明白为什么有时候adb disconnect对 USB 设备无效——因为 USB 连接根本不是通过disconnect管理的，它走的是另一套逻辑。下面逐个拆解。
3. 删除 offline 设备的四种手段与适用场景
3.1 手段一：adb disconnect，专治 TCP 无线调试残留
如果你用的是无线调试（adb tcpip或 Android 11+ 的无线调试配对），offline条目大概率是 TCP 连接残留。这时候首选：
adb disconnect 192.168.1.100:5555把 IP 和端口换成你adb devices里看到的那条 offline 记录。执行成功会返回disconnected 192.168.1.100:5555。
这里有个细节：端口必须写全。很多人只写 IP 不写端口，ADB 会默认用 5555，但如果你的设备实际端口是随机分配的（Android 11+ 无线调试常见），就会报error: no such device。所以第一步永远是先adb devices看清楚完整的IP:PORT。
还有一个坑：如果这条 offline 记录的端口是0或者明显不正常的数字，说明 Server 里的连接信息已经损坏，disconnect大概率无效，直接跳到手段三。
3.2 手段二：adb kill-server 配合 start-server，万能重置
这是最常用也最粗暴的办法，对 USB 和 TCP 都有效：
adb kill-server adb start-server adb deviceskill-server会把整个 ADB Server 进程杀掉，内存里的设备表随之清空。start-server重新拉起一个干净的 Server，它会重新扫描当前实际连接的设备。那些物理上已经拔掉的、或者连接已经断掉的 offline 条目，自然就不会再出现。
但注意，这个办法不是每次都灵。如果设备物理上还插着，只是 adbd 卡死，那么重启 Server 后它可能又被重新识别成 offline。这时候问题不在 Server，而在设备端的 adbd，需要配合手段四。
提示：
kill-server之后如果start-server卡住不动，通常是端口 5037 被占用。可以用netstat -ano | findstr 5037（Windows）或lsof -i :5037（macOS/Linux）查一下是谁占着。
3.3 手段三：直接操作 ADB Server 端口，精准踢设备
这是很多人不知道的一招。ADB Server 在本地监听5037 端口，它有一套文本协议。你可以直接连上去发指令，实现比命令行更细粒度的控制。比如查询当前设备列表：
# Linux/macOS echo "host:devices" | nc localhost 5037 # Windows 可以用 telnet telnet localhost 5037 # 然后输入 host:devices返回的内容里会包含设备的序列号和状态。虽然标准协议里没有直接“删除某个 USB 设备”的命令，但通过host:disconnect:<地址>可以断开指定 TCP 设备，效果和adb disconnect一样，只是绕过了命令行封装，在某些adb命令本身报错的情况下反而能用。
这一招的价值在于排查：当adb devices显示的结果和你预期不符时，直接问 Server 要原始数据，能判断到底是 Server 状态错了，还是命令行工具显示错了。
3.4 手段四：从设备端和系统层解决根因
如果上面三招都试过，offline 还是反复出现，那问题多半不在 ADB Server，而在更底层。按这个顺序排查：
第一，换线换口。劣质 USB 线是 offline 的头号元凶。我实测过一根某宝九块九的线，插上就 offline，换原装线立刻正常。优先插主板后置 USB 口，别用前面板或扩展坞。
第二，重启设备端 adbd。在设备上（如果有 root 或调试权限）执行：
adb shell stop adbd adb shell start adbd但 offline 状态下adb shell本来就进不去，所以这招通常要在设备能正常连接时提前做，或者直接在设备上开发者选项里关掉再打开 USB 调试。
第三，清理电脑端 USB 驱动状态。Windows 上可以在设备管理器里找到对应设备，卸载后重新插拔；Linux 上检查 udev 规则是否正确，lsusb看设备有没有被识别。
第四，检查是否有多个 ADB 版本冲突。比如同时装了 Android Studio 自带的 adb 和单独下载的 platform-tools，两个版本不一致会导致协议握手失败。用adb version确认，并确保 PATH 里只有一个。
4. 一套可复现的完整清理流程
4.1 标准操作顺序
把上面的手段串成一条流水线，遇到 offline 就按这个顺序走，基本能覆盖 95% 的情况：
- 看清楚：
adb devices -l，记下 offline 条目的完整标识（序列号或 IP:PORT）。 - 判断类型：标识里带
:的是 TCP 设备，纯字母数字的是 USB 设备。 - TCP 优先 disconnect：
adb disconnect <IP:PORT>。 - 无效则重置 Server：
adb kill-server && adb start-server。 - 仍无效查端口占用：确认 5037 没被别的程序占。
- 还无效查物理层：换线、换口、重启设备 USB 调试。
- 终极手段：重启电脑（是的，有时候就是这么朴实无华）。
4.2 批量清理脚本
如果你做自动化测试，设备多，手动一条条删不现实。可以写个脚本自动识别并清理 offline 设备。下面是一个 Linux/macOS 下的 bash 示例：
#!/bin/bash # 自动断开所有 offline 的 TCP 设备 adb devices | grep "offline" | while read line; do addr=$(echo $line | awk '{print $1}') if [[ $addr == *":"* ]]; then echo "Disconnecting offline device: $addr" adb disconnect $addr fi done # 清理完再重置一次 server 兜底 adb kill-server adb start-server adb devicesWindows 下可以用 PowerShell 实现类似逻辑：
$devices = adb devices | Select-String "offline" foreach ($d in $devices) { $addr = ($d -split "\s+")[0] if ($addr -match ":") { Write-Host "Disconnecting $addr" adb disconnect $addr } } adb kill-server adb start-server adb devices注意：脚本里只对带冒号的 TCP 设备做 disconnect，USB 设备交给 kill-server 处理。如果无脑对所有 offline 条目执行 disconnect，USB 设备会报错刷屏，虽然不影响结果但看着糟心。
4.3 参数与判断依据说明
为什么脚本里要先判断冒号？因为adb disconnect的语法只接受host:port格式。你给它一个 USB 序列号，它会返回error: no such device。这不是 bug，是设计如此——USB 连接的生命周期由 Server 的 USB 监听线程管理，不走 disconnect 通道。
为什么清理完还要再 kill-server 一次？因为disconnect只断开指定连接，Server 里可能还有其他残留状态。重置一次能保证设备表干净。这个组合拳我在多设备测试环境里用了很久，比单纯 kill-server 更彻底，因为它先把能优雅断开的断开，再统一重置。
5. 常见问题速查与避坑心得
5.1 问题速查表
| 现象 | 可能原因 | 解决方向 |
|---|---|---|
| disconnect 报 no such device | 地址写错或端口不全 | 用 adb devices 核对完整地址 |
| kill-server 后设备又变 offline | 设备端 adbd 卡死 | 重启设备 USB 调试或重启设备 |
| start-server 卡住 | 5037 端口被占用 | 查占用进程并结束 |
| 同一设备出现两条记录 | 重复注册 | kill-server 重置 |
| offline 且 unauthorized 交替出现 | 调试授权密钥冲突 | 撤销 USB 调试授权后重新授权 |
| 只有某台特定设备 offline | 该设备线材或接口问题 | 换线换口单独排查 |
| 所有设备都 offline | ADB 版本或驱动问题 | 统一 ADB 版本，重装驱动 |
5.2 几个我踩过的坑
坑一：以为 offline 是设备问题，其实是线。有次排查了半小时 ADB 配置，最后发现是 USB 线内部断了一根数据线，只能供电不能传数据。所以遇到 offline，第一反应应该是换线，而不是折腾命令。
坑二：adb kill-server需要权限。在某些 Linux 发行版上，普通用户执行 kill-server 可能因为权限不足失败。加sudo或者配置好 udev 规则后用普通用户运行。但注意别用 sudo 启动 server 后又用普通用户连，会导致权限混乱，反而制造新的 offline。
坑三：无线调试的端口会变。Android 11 之后的无线调试，每次配对端口可能不同，而且设备重启后端口也会变。如果你脚本里写死了 5555，很可能连到别的设备或者连不上。正确做法是每次从adb devices动态读取。
坑四：模拟器也会 offline。别以为只有真机会出问题，模拟器（尤其是第三方模拟器）的 ADB 端口冲突时也会 offline。这时候要检查模拟器自带的 adb 和你系统里的 adb 是不是打架了。
坑五：adb reconnect值得一试。这个命令相对冷门，但它能让 Server 主动重新连接 offline 设备：
adb reconnect offline它会尝试把所有 offline 设备重新拉回在线状态。如果设备其实还连着，只是握手失败，这招有时比 kill-server 更温和，不用重建整个 Server。
5.3 预防比清理更重要
与其每次出问题再删，不如从源头减少 offline 的出现：
- 固定使用一根质量好的数据线，别随手抓。
- 无线调试用完及时
adb disconnect，别让它挂着。 - 多设备环境给每台设备固定端口，避免端口漂移。
- 保持 ADB 版本统一，别让多个版本共存。
- 自动化脚本里加健康检查，发现 offline 自动清理并告警。
我个人在实际操作中的体会是，offline 这个问题八成靠“换线 + kill-server”就能解决，剩下两成里有一半是端口占用，最后那一小半才是真正棘手的驱动或协议问题。把上面这套流程走一遍，基本不用再靠重启电脑这种终极手段了。最后再分享一个小技巧：如果你经常需要批量管理设备，可以把清理逻辑做成一个定时任务，每隔几分钟扫一次adb devices，发现 offline 就自动处理，这样调试环境能一直保持干净。
