Debian 下蓝牙耳机断连通常不是单一故障点，而是蓝牙链路、音频会话和 USB 电源管理三层叠加的结果。实际处理时要先分清耳机是从 HCI 层面彻底断开，还是仅 A2DP 音频流被暂停。前者在 bluetoothctl info 里会显示设备已断开，后者连接状态仍然存在，但 pactl 或 wpctl 中看不到输出设备。本文以 Debian 12/13 和 BlueZ 5.x 为背景，按链路层、音频层、电源管理三个方向逐一排查，并给出可以长期保持连接的配置方法。
一、先确定断连发生在哪一层
判断断连层级最直接的方法是观察 HCI 状态。打开终端后进入 bluetoothctl，连接耳机并持续播放音乐，如果断连时终端里显示 Device XX:XX:XX:XX:XX:XX disconnected，说明问题来自蓝牙链路或适配器。若终端没有变化，但声音突然消失，则更可能是音频服务释放了 A2DP 会话。
bluetoothctl [bluetooth]# power on [bluetooth]# scan on [bluetooth]# connect 38:18:4C:12:34:56 [bluetooth]# info 38:18:4C:12:34:56
其中 info 输出的 Connected: yes 和 UUID: Audio Sink 两项非常关键。如果连接断开后自动重连又失败，可以使用 journalctl -u bluetooth -f 同步查看 BlueZ 日志。日志中经常会出现 Reason: Connection Timeout、Page Timeout 或 Disconnected by remote，这些信息能区分是本地主动断开还是耳机端断开。
音频层可以并行检查。PulseAudio 时代执行 pactl list cards | grep -i bluez，PipeWire 桌面则执行 wpctl status。如果断连时蓝牙设备仍显示为已连接，但输出端消失，说明是音频策略或编解码协商失败，此时重启蓝牙服务并不能解决问题，应该重点调整音频会话参数。
二、关闭适配器省电导致的静默断连
很多 USB 蓝牙适配器默认启用了自动挂起，系统会在空闲或低负载时把适配器电源状态从 on 切换到 auto，部分芯片在这种状态下无法维持 HCI 连接，表现就是耳机每几十分钟断一次。检查方法是先通过 lsusb 找到蓝牙适配器的编号，再查看内核电源管理文件。
lsusb # 例如 Bus 001 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle cat /sys/bus/usb/devices/1-3/power/control
如果输出为 auto，可以临时写 on 验证问题是否消失，命令为 echo on | sudo tee /sys/bus/usb/devices/1-3/power/control。但 USB 设备路径会随重启变化，长期修复需要编写 udev 规则。将下面的内容保存到 /etc/udev/rules.d/50-bluetooth-usb.rules。
ACTION=="add", SUBSYSTEM=="usb", DRIVER=="btusb", ATTR{power/control}="on"
保存后执行 sudo udevadm control --reload-rules 和 sudo udevadm trigger，之后重新插拔适配器，/sys/bus/usb/devices/.../power/control 会被固定为 on。需要注意的是，关闭自动挂起会增加极少量 USB 功耗，对笔记本电池影响有限，却能明显减少蓝牙掉线。
除了 USB 层面，BlueZ 自己的策略也会让部分耳机进入节能状态。可以编辑 /etc/bluetooth/main.conf，在 [General] 段中确认或加入以下配置。
[General] AutoEnable=true DiscoverableTimeout=0 FastConnectable=true [Policy] AutoEnable=true
修改后执行 sudo systemctl restart bluetooth 使其生效。这里 FastConnectable 会提高重连时的寻呼速度，但也会略微增加功耗；对频繁断连的耳机来说，重连速度比省电更重要。
三、固定音频编解码与自动切换策略
蓝牙耳机在 A2DP 和 HFP/HSP 之间反复切换是造成断连的另一大原因。比如某些视频会议应用打开麦克风时，PipeWire 会从高质量 A2DP 切到低质量 HFP，关闭麦克风后再切回，切换过程中编解码协商一旦超时，音频会话就会直接消失。Debian 12 以后默认使用 PipeWire 作为音频服务，因此优先调整 PipeWire 的 BlueZ 参数。
monitor.bluez.properties = {
bluez5.enable-sbc-xq = true
bluez5.enable-msbc = true
bluez5.enable-hw-volume = true
bluez5.roles = [ a2dp_sink a2dp_source hfp_hf hfp_ag ]
bluez5.codecs = [ sbc aac ]
bluez5.auto-connect = true
}
将以上内容写入 ~/.config/pipewire/pipewire.conf.d/bluez.conf，然后执行 systemctl --user restart pipewire pipewire-pulse。其中 bluez5.roles 限制了允许加载的音频角色，如果耳机只用于听音乐，可以把 hfp_hf 和 hfp_ag 删除，避免麦克风打开时触发协议切换。不过删除后视频会议将无法使用麦克风，可根据实际场景取舍。
如果仍在使用 PulseAudio，则可以编辑 /etc/pulse/default.pa，确保加载了 BlueZ 自动发现模块，并在 daemon.conf 中增加重连容忍参数。
load-module module-bluez5-discover load-module module-switch-on-connect exit-idle-time = -1
module-switch-on-connect 本来用于接入新设备时自动切换输出，但在部分蓝牙耳机上会频繁抢占默认声卡，导致 A2DP 会话被中断。可以尝试去掉这一行，或者只在有多个输出设备时才启用。另一项值得调整的是编解码优先级，固定使用 SBC 或 AAC，避免耳机反复请求不支持的编码。
四、用日志与 HCI 抓包定位偶发问题
经过上述配置后如果仍偶发断连，需要从 HCI 包和内核日志中寻找更具体的错误来源。BlueZ 自带 btmon 工具，可以在后台记录完整的 HCI 交互。抓包前先停止蓝牙服务并不影响测试，记录完成后用 btmon -r trace.log 回读。
sudo btmon -w /tmp/bt-trace.log # 保持运行并复现断连 sudo btmon -r /tmp/bt-trace.log | grep -E "Disconnect|Reason|Codec"
日志中如果出现 LL Supervision Timeout，通常说明耳机与适配器之间的链路质量差，2.4GHz Wi-Fi 干扰是常见诱因。可以把路由器 2.4GHz 频段固定在 1、6、11 信道，或者让耳机尽量靠近适配器。若笔记本自带蓝牙，还应该尝试关闭 Wi-Fi 省电模式，命令为 sudo iwconfig wlp2s0 power off。
部分老旧蓝牙芯片对 BlueZ 默认启用的 ERTM 流控支持不佳，会出现连接几秒后断开的情况。可以在内核模块参数中关闭该特性。创建 /etc/modprobe.d/btusb.conf，内容如下。
options btusb disable_ertm=1
保存后执行 sudo modprobe -r btusb 再 sudo modprobe btusb，或者重启系统。这一项只对特定芯片有效，新适配器不建议默认关闭，否则会牺牲重传效率。最稳妥的做法仍然是先把省电配置固定，再用 bluetoothctl 和 pactl 同步观察，根据工具输出决定是继续调整音频策略，还是替换适配器固件。
蓝牙耳机断连处理不是找到一个命令就结束，而是按照 HCI 链路、音频会话、电源管理三个层级逐步收敛。先把断连层级确定下来，再针对那一层做配置变更，就能避免盲目重启服务后问题仍然复现。对于 Debian 桌面用户来说，关闭 USB 自动挂起和固定 PipeWire 的 BlueZ 角色通常是收益最大的两步。
