嗨，从你描述的现象——重连时服务器收不到连接请求，但重启蓝牙就正常——来看，这几乎都是连接断开后资源没彻底释放或者蓝牙栈残留了旧连接状态导致的。我帮你梳理几个最常见的排查和修复方向：

1. 断开连接时必须彻底清理Socket及流资源 #

很多人只调用了Socket.close()就完事，但Android蓝牙栈对资源释放要求很严格：

• 客户端和服务器两端，都要依次关闭InputStream、OutputStream，最后关闭BluetoothSocket，并且把这些对象置为null，避免引用残留占用资源。
• 重连时绝对不能复用旧的BluetoothSocket实例，必须重新通过device.createRfcommSocketToServiceRecord(uuid)创建新的Socket。

给你个客户端断开逻辑的示例：

private void cleanUpConnection() {
    // 先关闭流，再关闭Socket
    try {
        if (mmInputStream != null) mmInputStream.close();
        if (mmOutputStream != null) mmOutputStream.close();
        if (mmSocket != null) mmSocket.close();
    } catch (IOException e) {
        // 这里可以打印日志，但别因为异常中断清理流程
        Log.e("Bluetooth", "Cleanup failed", e);
    }
    // 置空，确保不会复用旧对象
    mmInputStream = null;
    mmOutputStream = null;
    mmSocket = null;
}

2. 服务器端要维持持续监听 #

如果你的服务器端监听线程是单次执行的（比如只调用了一次accept()），那当客户端断开后，这个线程可能因为IO异常退出，导致服务器不再监听新请求。你需要：

• 把服务器的accept()放在一个循环里，捕获到断开异常后，立刻重新调用accept()等待新连接。
• 确保服务器的BluetoothServerSocket不会因为一次连接失败就被关闭，除非你主动要停止服务。

3. 重连前重置蓝牙栈状态（不用重启蓝牙） #

有时候即使清理了资源，蓝牙栈还是会处于异常状态。你可以在重连失败时尝试：

• 先调用BluetoothAdapter.cancelDiscovery()（如果之前开了设备发现），然后执行上面的清理逻辑，再重新发起连接。
• 不要直接让用户重启蓝牙（体验太差），如果实在需要重置蓝牙，可以调用BluetoothAdapter.disable()再enable()，但这个操作需要BLUETOOTH_ADMIN权限，建议作为最后手段。

4. 检查UUID和连接流程的一致性 #

• 确保重连时用的UUID和第一次连接完全一致，UUID是蓝牙服务的唯一标识，错一点都连不上。
• 重连的流程要和第一次连接完全相同：比如先获取设备、创建Socket、调用connect()，不要跳过任何步骤。

5. 避免多线程竞态问题 #

如果你的重连操作是在多个线程触发的（比如按钮点击多次），可能导致多个Socket同时请求连接，打乱蓝牙栈的状态。建议加个全局状态标记，比如isConnecting，确保同一时间只有一个连接操作在执行。

最后，建议你在重连前后加详细日志，打印客户端的蓝牙状态、Socket是否为null、是否成功发起connect()，服务器端也打印监听线程的状态，这样能更快定位到哪一步出了问题。

内容的提问来源于stack exchange，提问作者Max N