5037端口被adb自己占用

下午三点，端口Android开发工具突然罢工。自己占用adb devices列出空列表，端口可模拟器明明在跑。自己占用翻日志，端口发现5037端口被占用——不是自己占用别的进程，是端口adb自己。

这毛病我遇过不下五次。自己占用每次都得kill掉所有adb进程再重启，端口像给电脑做心肺复苏。自己占用可为什么adb会自己占自己的端口端口？查了一圈，问题出在adb server的自己占用启动机制上。

adb靠一个server进程管理所有设备通信，端口这个server默认监听5037。自己占用当你连着设备，端口又用不同用户权限或不同环境变量启动adb时，系统可能拉起第二个server。第二个server发现端口被占，本该退出，但它没退干净——残留进程还握着端口。第一个server反而被误判为异常，新请求全被拒。

更常见的是IDE和命令行混用。Android Studio自带adb，你终端里也配了adb。两个版本不同，路径不同，启动时各拉各的server。后启动的检测到端口冲突，本该报错退出，但某些版本会静默失败，留下僵尸进程。这时候你看到的就是adb占用了自己的端口。

还有个隐蔽场景：USB断开重连时，adb server在等设备响应，此时你手动执行adb kill-server，紧接着adb start-server。旧server还没完全释放socket，新server已经抢着绑端口——绑定失败，但进程没死，处于半瘫痪状态。这种状态最坑，进程列表里看着正常，实际啥也干不了。

解决办法其实粗暴有效：
1. adb kill-server
2. 检查5037端口：netstat -ano | findstr 5037（Windows）或lsof -i:5037（Mac/Linux）
3. 找到残留PID，直接kill -9（Windows下taskkill /F /PID）
4. 重新adb start-server

还不够的话，查环境变量。终端里which adb和Android Studio的SDK路径是否一致。不一致就统一成一个版本，别让两个adb打架。

说到底，这是adb设计上的一个坑——server进程没有做端口占用的强校验，只靠“发现冲突就退出”的软逻辑。遇上进程调度延迟或异常退出，这逻辑就漏了。Google在后续版本加了端口互斥锁，但老版本和某些厂商定制版还是老样子。

现在每次连不上设备，我第一反应不是查驱动，而是先看5037。十有八九又是adb自己人打自己人。你遇到过没？评论区聊聊，看看还有啥奇葩占用姿势。