选型取决于平台和用途：Linux Peripheral 用 paypal/gatt，Linux Central 用 muka/go-bluetooth，跨平台 Central 用 elliotchance/ble；环境配置（权限、bluez、HCI 状态）比代码更关键。
用哪个库？别被名字带偏了
Go 语言做 BLE 通信，目前没有“官方标准库”，实际选型取决于你的目标平台和用途。不是所有叫 gatt、ble、bluetooth 的包都能在你机器上跑起来——关键看底层依赖是否就位。
-
github.com/paypal/gatt：专注 BLE 外设（Peripheral） 场景，比如模拟一个心率计或温度传感器；它直接操作 HCI 设备（如/dev/hci0），Linux 下必须装libbluetooth-dev和bluez，macOS 可直接跑；但它不支持 Central（扫描/连接别人）模式 -
github.com/muka/go-bluetooth：纯 BlueZ D-Bus 封装，只适用于 Linux；它不碰 HCI，而是调用org.bluez总线接口，适合做设备发现、配对、GATT 客户端读写；但无法在 macOS 或 Windows 上运行 -
github.com/currantlabs/ble（已归档）和它的继任者github.com/elliotchance/ble：跨平台设计，Central 模式稳定，适合做扫描器或连接 BLE 设备；但 Peripheral 功能弱或缺失，且部分版本对 macOS 14+ 或 Linux kernel 6.x 支持不稳定
常见错误现象：failed to open device: no such file or directory —— 很可能你用了 gatt 却没开 bluetoothd，或没用 sudo 启动（Linux 下 HCI 访问需要 root）；又或者你在 macOS 上跑了 Linux 专用的 go-bluetooth，根本连 D-Bus 都连不上。
Linux 下跑 Peripheral：权限和 BlueZ 状态比代码还重要
gatt.NewDevice() 失败，90% 不是 Go 写错了，而是系统环境没准备好。
- 必须确保
bluetoothd进程正在运行：systemctl is-active bluetooth返回active，否则gatt初始化会卡住或报错 - HCI 设备需处于 UP 状态：
sudo hciconfig hci0 up；如果提示Can't init device hci0: Connection refused (111)，说明bluetoothd没管这个控制器，要检查/etc/bluetooth/main.conf中Enable=Source,Sink,Media,Socket,Gateway,ControlPanel是否包含LE - 不要跳过
rfkill检查：rfkill list bluetooth，若显示Soft blocked: yes，得先rfkill unblock bluetooth
示例中常看到这行：d, err := gatt.NewDevice(option.DefaultServerOptions)。注意 DefaultServerOptions 在 Linux 下默认绑定 hci0，如果你有多个蓝牙适配器（比如 USB 蓝牙狗），得显式传入 option.ServerWithDeviceID("hci1")，否则可能连错硬件。
立即学习“go语言免费学习笔记（深入）”；
扫描设备却啥也没发现？检查广播模式和权限层级
用 go-bluetooth 或 ble 扫描不到设备，往往不是代码漏了 Start()，而是：
- 目标设备本身没开启可发现模式（Discoverable）或未发送广播包（Advertising）；BLE 外设若只响应连接、不广播，就不可能被扫到
- Linux 下，普通用户默认无权访问 BlueZ D-Bus 接口；要么加进
lp组（sudo usermod -a -G lp $USER），要么用sudo运行程序（不推荐用于长期服务） - macOS 上，
ble库依赖 CoreBluetooth 框架，而该框架在非交互式上下文（如 systemd 服务、SSH 远程终端）中会被静默禁用；必须在 GUI 登录会话下运行 - 广播数据长度超限也会导致丢包：BLE 广播包最大 31 字节，若自定义服务 UUID + 名称 + TX Power 全塞进去，容易截断，让扫描端解析失败
一个快速验证方式：sudo hcitool lescan（Linux）或 bluetoothctl scan on（BlueZ CLI）。如果这些命令也扫不到，问题一定出在物理层或对方设备配置，跟 Go 代码无关。
读写 Characteristic 总是 timeout？别硬等，要看连接状态和 MTU
BLE 通信里最常卡住的不是连接，而是第一次 WriteValue 或 ReadValue —— 报 timeout 或 connection refused。
- 必须确认 Central 已成功建立连接且进入
Connected状态；很多库（如ble）的Connect()是异步的，返回的*Client对象不等于已连上，得监听client.OnConnected回调再操作 - 默认 ATT MTU 是 23 字节；如果要写超过 20 字节的数据（扣除 ATT header），必须先协商增大 MTU：
client.ExchangeMTU(128)；否则大包会被静默截断或触发重传超时 - iOS/macOS 对未签名的 BLE 特征（Characteristic）有更严的隐私限制；若服务 UUID 是随机生成的 128-bit，某些手机系统会直接拒绝读写，换成标准 UUID（如
00002a19-0000-1000-8000-00805f9b34fb电池电量）更容易通过
容易被忽略的地方：BLE 连接非常脆弱，Wi-Fi 2.4GHz 干扰、USB 3.0 设备靠近、甚至笔记本盖子合上都可能导致链路中断；不要假设一次 Connect() 能维持数小时——得自己实现重连逻辑，且重连前务必调用 client.Disconnect() 清理资源，否则新连接可能失败。
