上个月给客户做现场演示，会议室那台演示电脑旁边找不到无线键鼠，现场翻遍抽屉只有一台手机。我打开自己写过的一个小工具，花3分钟把手机变成了蓝牙键盘和鼠标，直接在演示机上切PPT、敲命令，整套演示流程没让客户看出半点临时救场的狼狈。后来这个方案被我越改越完整，在近场蓝牙HID之外加了一层Serverless信令服务，让手机即使不在同一个房间，也能向家里书房、公司工位甚至实验室的电脑发送键鼠指令。这篇文章就完整还原这套"手机秒变蓝牙键鼠"的跨设备控制方案，从BLE HID协议原理、Android端实现、Serverless信令中转，到远端代理程序的落地细节一次讲清楚。
1. 从"临时找键鼠"到"手机即键鼠"：这个方案到底在解决什么问题
先说场景。我最初做这个工具，纯粹是为了解决一个很常见但一直没人好好解决的痛点：临时需要控制一台电脑，但手边没有键鼠。比如会议室投屏调试、智能电视装应用、树莓派接显示器、工控机没有外设、演示现场主机藏在讲台下面不方便操作……这些场景下，最痛苦的不是"没有键鼠"，而是"临时找一个键鼠的成本远高于实际操作的分钟数"。
市面上已有的手机遥控类App，大多数走的是局域网协议，比如装一个PC客户端，再在手机上装App，通过Wi-Fi收发指令。这类方案的问题在于：每台目标电脑都要预装客户端、配对繁琐、且必须处于同一局域网。而另一类"手机当键鼠"的工具要么闭源收费、要么只支持特定品牌的电脑或电视，用起来总有一层隔阂。
所以我把目标拆成两层：
- 近场层：手机通过蓝牙HID协议，直接伪装成标准蓝牙键鼠，电脑、电视、车机、平板都能直接识别，不需要在目标设备上安装任何东西。
- 远程层：手机通过Serverless信令服务，把键鼠指令转发给跑在目标电脑上的代理程序，实现跨网络的控制能力。
两套链路共用同一套手机端输入界面和同一套指令协议，区别只在传输通道。近场零安装、零配置，远程走公网、可穿透不同网络。做完之后我发现，这个组合几乎覆盖了我在实际工作里遇到的所有"临时要控一台设备"的场景。
受益人群也很明确：经常跑现场做演示的工程师、运维调试人员、做嵌入式开发时频繁操作开发板或工控机的朋友、家里电视或客厅电脑懒得配键鼠的人，以及需要在不同网络之间远程操作办公电脑的上班族。
2. 技术底座：BLE HID协议与Serverless信令层分别是干什么的
要理解这套方案，得先分清两个核心技术各自扮演的角色。它们解决的问题完全不在同一个层面，却正好互补。
2.1 BLE HID：让手机在蓝牙层面"伪装"成标准键鼠
BLE HID全称是HID over GATT Profile，属于蓝牙低功耗规范里的一个标准Profile。它的本质是：把键盘、鼠标这类人机交互设备的报告数据（Report）封装成BLE GATT服务，让接收端像读取普通蓝牙键鼠一样读取数据。
传统蓝牙键鼠走的是BR/EDR（经典蓝牙）通道，用HID Profile传输。而BLE HID走的是低功耗蓝牙通道，用GATT服务来暴露报告数据。对接收设备来说，只要有BLE模块并且支持HID over GATT，就能把发送端认成标准键鼠。
手机变身键鼠的关键就在这里。手机硬件本身就带BLE芯片，系统也具备BLE外设角色（Peripheral）能力，只要通过系统API注册一个自定义的HID设备服务，然后向连接方发送标准格式的HID报告，接收方就会认为是有一个蓝牙键鼠连接进来了。整个过程在系统层面完成，接收端不需要安装任何App或驱动。
HID报告本身是固定格式的二进制数据。一个标准键盘报告通常是8个字节：第1字节是修饰键（Ctrl、Shift、Alt、Win等），第2字节保留，后6字节是当前按下的按键编码。一个标准鼠标报告则包含按钮状态、X轴位移、Y轴位移、滚轮数据。发送端只要按照接收端期望的Report Descriptor格式去填充这些字节，事件就会被解析成真实的键鼠输入。
2.2 Serverless信令层：解决"不在同一个蓝牙范围"的问题
蓝牙HID有一个天然边界：通信距离通常只有10米左右，而且蓝牙键鼠模式是点对点连接。如果我想在相隔几十公里的地方控制家里的电脑，蓝牙这条路完全走不通，这时候就需要一条互联网通道。
为什么选择Serverless而不是一台传统云服务器？核心原因有三个：
- 几乎零成本维持在线状态：这套方案的信令通道大部分时间是空闲的，只在按键事件发生时才有数据流动。传统云服务器需要7x24小时开机，而Serverless按调用次数和运行时长计费，空闲期和低流量期费用趋近于零。
- 免运维，天然适合个人工具：自己维护一台服务器涉及操作系统升级、安全补丁、进程守护、DDOS防护等等，对于为了"控个电脑"而搭建的辅助工具来说，运维负担和收益完全不成正比。
- WebSocket长连接支持很成熟：Serverless平台基本都提供了WebSocket触发器，天然适合做双向实时信令转发，不需要额外部署Nginx、Redis做连接管理。
简而言之，BLE HID解决的是"手机在物理层变成键鼠"，Serverless解决的是"键鼠指令如何跨网络到达目标设备"。两个技术叠加，最终形成一套近场零安装、远程免服务器的完整控制方案。
3. Android手机变身蓝牙键鼠：BluetoothHidDevice API的落地细节
近场部分是整个方案的入口，也是我踩坑最多的地方。Android从9.0开始提供了官方APIBluetoothHidDevice，支持让手机作为HID设备（也叫HID Device角色）向远端发送键鼠报告。iOS由于系统限制，目前没有公开API允许iPhone化身HID键鼠，所以近场这条链路我基于Android实现。
3.1 权限与系统版本：最容易卡住的地方
首先明确版本要求：Android 9（API 28）及以上版本才支持BluetoothHidDeviceAPI。另外不是所有Android手机都支持"外设角色"，部分中低端机型的蓝牙固件只实现了一端，需要在真机上验证。
权限方面，除了常规的蓝牙权限，还有一个隐藏要求：BLUETOOTH_CONNECT（Android 12+）以及通过CompanionDeviceManager申请设备过滤。Android 12之后的蓝牙权限粒度更细，如果没有正确申请，会在连接阶段直接抛出SecurityException，这个在低版本上不会出现，很多移植代码翻车都是栽在这。
示例代码如下，简化版直接在Activity中注册HID设备：
val bluetoothManager = getSystemService(BluetoothManager::class.java) val bluetoothAdapter = bluetoothManager.adapter // Android 12+ 需要动态申请 BLUETOOTH_CONNECT if (Build.VERSION.SDK_INT >= 31) { requestPermissions(arrayOf(Manifest.permission.BLUETOOTH_CONNECT), REQUEST_BT_CONNECT) } val hidDeviceProfile: BluetoothHidDevice? = bluetoothAdapter.getProfileManager() .getProfile(this, BluetoothHidDevice::class.java) hidDeviceProfile?.registerApp( sdpRecord = BluetoothHidDevice.SDP_RECORD, inQos = null, outQos = null, executor = Executors.newSingleThreadExecutor(), callback = object : BluetoothHidDevice.Callback() { override fun onConnectionStateChanged(device: BluetoothDevice?, state: Int) { // 连接状态变化 } override fun onGetReport(device: BluetoothDevice?, type: Byte, id: Byte, bufferSize: Int) { // 远端请求报告 } override fun onSetReport(device: BluetoothDevice?, type: Byte, id: Byte, data: ByteArray?) { // 远端设置报告，部分系统会触发 } } ) { success -> if (success) { Log.d("HidDevice", "注册成功") } else { Log.e("HidDevice", "注册失败，通常由权限不足或设备不支持导致") } }SDP_RECORD是系统为HID设备预置的服务发现记录，这行代码决定了目标设备在蓝牙配对列表里看到的名字和能力标识。
注意：
registerApp注册的是"本机可以作为一个HID设备"的服务能力，但它不主动发起连接。真正建立连接需要从手机端发起connect(device)，或者由远端设备主动搜索并配对手机。实测下来，由手机主动connect成功率更高，因为远端设备（比如Windows）的蓝牙键鼠配对引导不会自动识别新设备。
3.2 HID Report Descriptor与键盘事件发送：核心的二进制协议
注册成功后，核心工作就是构造并发送HID报告。报告格式必须和Report Descriptor严格一致，否则接收端会忽略数据或识别成未知设备。
下面是我用到的合并描述符，包含鼠标和键盘两套报告：
static const uint8_t reportDescriptor[] = { // 鼠标 0x05, 0x01, // Usage Page (Generic Desktop) 0x09, 0x02, // Usage (Mouse) 0xA1, 0x01, // Collection (Application) 0x09, 0x01, // Usage (Pointer) 0xA1, 0x00, // Collection (Physical) 0x05, 0x09, // Usage Page (Button) 0x19, 0x01, // Usage Minimum (1) 0x29, 0x03, // Usage Maximum (3) 0x15, 0x00, // Logical Minimum (0) 0x25, 0x01, // Logical Maximum (1) 0x95, 0x03, // Report Count (3) 0x75, 0x01, // Report Size (1) 0x81, 0x02, // Input (Data, Variable, Absolute) 0x95, 0x01, // Report Count (1) 0x75, 0x05, // Report Size (5) 0x81, 0x01, // Input (Constant) 0x05, 0x01, // Usage Page (Generic Desktop) 0x09, 0x30, // Usage (X) 0x09, 0x31, // Usage (Y) 0x15, 0x81, // Logical Minimum (-127) 0x25, 0x7F, // Logical Maximum (127) 0x75, 0x08, // Report Size (8) 0x95, 0x02, // Report Count (2) 0x81, 0x06, // Input (Data, Variable, Relative) 0xC0, 0xC0, // End Collections // 键盘 0x05, 0x01, // Usage Page (Generic Desktop) 0x09, 0x06, // Usage (Keyboard) 0xA1, 0x01, // Collection (Application) 0x05, 0x07, // Usage Page (Keyboard) 0x19, 0xE0, // Usage Minimum (224) - Left Control 0x29, 0xE7, // Usage Maximum (231) - Right GUI 0x15, 0x00, // Logical Minimum (0) 0x25, 0x01, // Logical Maximum (1) 0x75, 0x01, // Report Size (1) 0x95, 0x08, // Report Count (8) 0x81, 0x02, // Input (Data, Variable, Absolute) 0x95, 0x01, // Report Count (1) 0x75, 0x08, // Report Size (8) 0x81, 0x01, // Input (Constant) 0x95, 0x06, // Report Count (6) 0x75, 0x08, // Report Size (8) 0x15, 0x00, // Logical Minimum (0) 0x25, 0x65, // Logical Maximum (101) 0x05, 0x07, // Usage Page (Keyboard) 0x19, 0x00, // Usage Minimum (0) 0x29, 0x65, // Usage Maximum (101) 0x81, 0x00, // Input (Data, Array) 0xC0 // End Collection };有了描述符，发送键盘事件就是构造8字节报告：
fun sendKeyReport(code: Byte, modifier: Byte, pressed: Boolean) { val report = ByteArray(8) report[0] = modifier if (pressed) { report[2] = code // 当前按下的按键 } hidDeviceProfile?.sendReport(device, reportId = 0, data = report) }这里重点说明两个细节：
report[2]是按键码（USB HID Keycode），不是ASCII码。比如字母A是0x04，B是0x05，数字1是0x1E，回车是0x28，普通键盘最左边那个修饰键（Ctrl）的编码属于修饰位，放在report[0]。- 发送"按下"和"抬起"是两个独立事件。按下时把按键码填充进数组，抬起时把对应位置清零。如果忘了发抬起事件，目标设备会认为这个物理按键一直被按住，表现就是输入框里连续输出同一个字符。
鼠标的报告则包含按钮状态、X位移、Y位移和滚轮，每次发送5字节左右：
fun sendMouseReport(button: Int, dx: Int, dy: Int, wheel: Int) { val report = ByteArray(5) report[0] = button.toByte() // 左键=0x01 右键=0x02 中键=0x04 report[1] = dx.toByte() // X轴相对位移 report[2] = dy.toByte() // Y轴相对位移 report[3] = wheel.toByte() // 滚轮 report[4] = 0 hidDeviceProfile?.sendReport(device, reportId = 0, data = report) }3.3 实测中的兼容性表现：哪些设备能识别、哪些会翻车
我把这套实现分别连了Windows 11笔记本、MacBook Pro、小米电视、树莓派4B，兼容性差异很大。
| 接收端 | 键盘 | 鼠标 | 备注 |
|---|---|---|---|
| Windows 11 | 正常 | 正常 | 识别为"无线键盘/鼠标" |
| macOS (Apple Silicon) | 正常 | 基本正常 | 鼠标加速度曲线略有差异 |
| 小米电视 (Android TV) | 正常 | 无法使用相对移动 | 需要改用绝对移动报告 |
| 树莓派 (Raspberry Pi OS) | 正常 | 正常 | Linux内核自带HID驱动 |
Android TV这类设备上，鼠标的"相对位移"报告不起作用，这是因为部分电视系统的事件处理只监听绝对坐标类HID设备（比如触控板），而不是纯鼠标的相对移动。处理办法是把设备的鼠标描述符从相对移动改为绝对移动（Absolute），或者干脆在电视场景下只提供键盘+方向键，避开鼠标兼容问题。
4. Serverless信令服务：设备绑定、在线状态与指令转发的核心设计
有了近场链路，接下来把控制能力扩展到公网。这层的定位是"信令枢纽"：手机端和远端代理程序各自通过WebSocket连上同一个Serverless函数，手机产生的键鼠事件经函数转发给代理程序，代理程序再模拟成物理输入。
4.1 整体数据流与协议设计
一条完整的远程按键链路长这样：
手机端App（输入界面）→ WebSocket消息 → Serverless信令函数 → WebSocket消息 → 目标电脑代理程序 → 解析指令 → 模拟键鼠事件 → 目标系统收到输入
消息协议我用JSON，结构固定，方便扩展。一个键盘事件示例：
{ "type": "key_event", "deviceId": "device_uuid", "token": "session_token", "payload": { "keycode": 4, "modifier": 2, "action": "down" } }一个鼠标事件示例：
{ "type": "mouse_event", "deviceId": "device_uuid", "token": "session_token", "payload": { "button": 1, "dx": 5, "dy": -3, "wheel": 0, "action": "move" } }协议里的deviceId用来绑定设备，token做会话鉴权。这个设计借鉴了MQTT的Topic结构思路，但消息量小、实时性要求高，直接用WebSocket更简洁，不需要额外维护一套消息队列。
4.2 在线状态管理：连接映射是核心
Serverless函数本身是无状态的，但WebSocket长连接要求保存"每个连接对应哪台设备"。我用云厂商自带的Redis做连接映射表，结构大概是这样：
- Key：
device_id - Value：WebSocket连接ID
- 过期时间：60秒，代理程序每30秒发一次心跳
当函数收到一条消息，先从JSON里取出deviceId，再到Redis查这个设备当前对应的WebSocket连接ID，然后通过平台提供的连接推送接口把消息转发过去。这套设计的核心思想是"连接状态与业务逻辑分离"——所有在线状态都存Redis，业务函数只做消息中转，这样函数实例扩容缩容都不会丢连接。
4.3 设备绑定与鉴权：不能裸奔
信令层的安全性是我反复打磨的重点。最初版本直接靠设备ID转发，结果任何人都可以伪造设备ID乱发消息，后来我加了完整的绑定和鉴权流程：
- 首次绑定：手机端生成一个一次性配对码，用户在目标电脑代理程序里输入这个配对码，代理程序带着配对码调用Serverless的绑定接口，Serverless把手机端和代理端绑定到同一个
deviceId下。 - 会话Token：绑定成功后，两端各自获得一个随机Token，后续所有WebSocket消息都必须携带Token。
- Token定期轮换：Token有效期12小时，过期后需要重新握手，降低泄露风险。
- 传输层强制WSS：WebSocket统一走TLS加密，不让明文指令在网络里裸奔。
为什么需要这个流程？因为键鼠指令本质上是"让别人替你操作电脑"的能力，一旦被别人劫持，等于给了对方一个远程控制你电脑的入口。绑定流程看起来多做了两步，但它是这套方案敢用于远程控制的关键底线。
4.4 冷启动与连接保活：Serverless场景的常见坑
Serverless函数在空闲一段时间后会释放实例，下一次消息进来需要冷启动，冷启动耗时通常在几百毫秒到几秒不等。对于键鼠控制来说，这种延迟是灾难性的——你按下一个键，半秒后字符才出现在屏幕上，手感完全不可用。
缓解办法有几个：
- 预留并发（Provisioned Concurrency）：给这个函数预留1个并发实例，基本消除冷启动。虽然会产生少量常驻费用，但和租一台云服务器相比还是便宜很多。
- 心跳保活：代理程序每30秒发一个心跳消息，函数收到心跳后做简单回包，同时让实例保持活跃。这个方案零成本，但只对单实例场景有效。
- 靠近目标设备的地域部署：函数部署地域尽可能靠近电脑所在城市，能省掉一大截网络RTT。
我实测下来，配上预留并发后，远程按键从手机端按下到电脑端响应，延迟稳定在150到300毫秒之间（取决于两端网络状况）。对这个场景来说，可接受。
5. 远端代理程序：让目标电脑真正"听懂"手机指令
Serverless把指令送达后，最终落地的是一段运行在目标电脑上的代理程序。这个程序的核心职责是：接收WebSocket消息，把JSON指令转换成系统级的键鼠事件。
5.1 三平台实现路线对比：Windows、macOS、Linux
不同操作系统的键鼠模拟接口差异很大，我分别做了适配：
| 系统 | 实现方式 | 核心API | 权限要求 |
|---|---|---|---|
| Windows | Python + pynput | keyboard.Controller/mouse.Controller | 无，但UAC提权窗口无法控制 |
| macOS | Python + Quartz | CGEventCreateKeyboardEvent | 需要在系统偏好设置里给终端授权"辅助功能" |
| Linux (X11) | Python + python-xlib | XTest扩展 | 无，但Wayland会话下不兼容 |
实际落地时，三个平台各有各的细节坑。
Windows上，pynput底层调用SendInput，这个API是全局性的，能覆盖绝大多数应用。但有一个限制：如果目标窗口以管理员权限运行，而代理程序不是管理员权限，SendInput无法把事件注入到那个管理员窗口。解决方法是让代理程序以管理员权限运行，或者接受这个限制、只控制普通权限窗口。
macOS上，最大的坑是辅助功能授权。Quartz事件接口要求运行代理的进程被授予"辅助功能"权限，否则调用会静默失败。而且授权的是"终端App"或"Python解释器"，不是代理程序本身——如果你换一个终端软件运行代理，需要重新授权。
Linux上，传统X11环境用XTest很稳定，但新一代Wayland会话里，XTest被默认禁止。Wayland下的键鼠模拟目前没有统一方案，我最终的做法是检测到会话类型后提示用户切换到Xorg，或者用ydotool走uinput内核接口，不过后者需要root权限，适用性有限。
5.2 一个能跑起来的Windows代理程序示例（Python）
以下是我Windows版本代理程序的核心骨架，去掉了日志和断线重连等外围逻辑，保留主干：
import json import threading from websocket import WebSocketApp from pynput.keyboard import Controller as KeyboardController, Key from pynput.mouse import Controller as MouseController keyboard = KeyboardController() mouse = MouseController() KEY_MAP = { 4: 'a', 5: 'b', 6: 'c', 7: 'd', 8: 'e', 9: 'f', 10: 'g', 11: 'h', 12: 'i', 13: 'j', 14: 'k', 15: 'l', 16: 'm', 17: 'n', 18: 'o', 19: 'p', 20: 'q', 21: 'r', 22: 's', 23: 't', 24: 'u', 25: 'v', 26: 'w', 27: 'x', 28: 'y', 29: 'z', 40: Key.enter, 42: Key.backspace, 43: Key.tab, 44: Key.space, 225: Key.shift } def handle_message(raw): msg = json.loads(raw) if msg['type'] == 'key_event': key = KEY_MAP.get(msg['payload']['keycode']) if not key: return if msg['payload']['action'] == 'down': keyboard.press(key) else: keyboard.release(key) elif msg['type'] == 'mouse_event': p = msg['payload'] if p['action'] == 'move': mouse.move(p['dx'], p['dy']) elif p['action'] == 'click': if p['button'] == 1: mouse.press(mouse.left) elif p['button'] == 2: mouse.press(mouse.right) # 注意：press之后要延迟release threading.Timer(0.05, mouse.release, args=(mouse.left if p['button'] == 1 else mouse.right,)).start() def on_message(ws, message): try: handle_message(message) except Exception as e: print('处理失败:', e) ws = WebSocketApp( 'wss://your-serverless-endpoint', on_message=on_message, header={'Authorization': 'Bearer <TOKEN>'} ) ws.run_forever()这段代码里我刻意保留了一个细节：鼠标点击的press和release之间要隔一点时间。如果按下和抬起在同一个时间片内，部分应用会判定为无效点击（尤其在Web页面里）。我用定时器隔了50毫秒再释放，实测点击成功率显著提升。
5.3 鼠标控制的"相对移动"与"绝对移动"之选
代理程序的鼠标控制有两种模式：相对移动和绝对移动。
相对移动就是上文HID报告里的dx/dy，表示"从当前光标位置往右/往上移动多少像素"。这种模式适合近场蓝牙控制，因为手机端的触摸板相当于一个相对偏移设备，手指滑动多少就移动多少。
但到了远程场景，相对移动的体验会变差：网络抖动时光标容易漂移，定位不准。绝对移动则直接把手机端发送的坐标映射到目标屏幕的绝对位置，比如手机屏幕上点了一个点，目标电脑的光标也跳到屏幕对应的百分比位置。手感和直接在目标电脑上操作触摸屏几乎一致。
两种模式在代理程序里可以用同一个消息结构表达，只是action字段区分——move表示相对移动，move_abs表示绝对移动，绝对移动的负载里传的是百分比坐标：
{ "type": "mouse_event", "deviceId": "device_uuid", "token": "session_token", "payload": { "action": "move_abs", "x_percent": 0.75, "y_percent": 0.3, "button": 0, "wheel": 0 } }代理端收到后：
from screeninfo import get_monitors def move_abs(x_percent, y_percent): monitor = get_monitors()[0] target_x = int(monitor.width * x_percent) target_y = int(monitor.height * y_percent) mouse.position = (target_x, target_y)这套绝对移动模式尤其适合"手机里显示一个缩小版的电脑桌面画面，手指点哪光标就去哪"的操作方式，远程控制体验上限高很多。
6. 端到端联调实测：延迟、稳定性与几组真实数据
写完两端之后，最关键的是把整条链路串起来看真实表现。我在三个典型场景下做了延迟测试：近场蓝牙直连、局域网WebSocket中转、公网WebSocket中转。
6.1 测试环境与测试方法
测试设备：
- 手机：一加Ace 3（Android 14）
- 目标电脑：Windows 11笔记本（网线连接路由器）
- Serverless：某云厂商WebSocket函数，部署在华东地域
- 网络：近场测试用手机蓝牙连电脑；局域网测试手机和电脑连同一个Wi-Fi；公网测试手机开5G网络
测试方法很简单：在手机端连续发送100次键盘事件，每次事件触发后，在电脑上用Python脚本记录收到并注入事件的时间戳，差值的平均值就是单次端到端延迟的近似值。这里忽略手机端本身的UI处理时间。
6.2 实测数据
| 控制路径 | 平均延迟 | 95%延迟 | 丢包率 |
|---|---|---|---|
| 蓝牙HID直连 | 28ms | 45ms | 0% |
| 局域网WebSocket中转 | 68ms | 110ms | 0.1% |
| 公网WebSocket中转（5G手机） | 220ms | 380ms | 0.5% |
蓝牙直连的28ms延迟比物理键盘略高，但普通人敲键盘根本感知不到。局域网68ms的延迟在输入场景下完全可接受，打游戏不适用，但打字、鼠标点击没有任何问题。
公网220ms的延迟就有点意思了。打字时字符几乎"跟着手指走"，但如果你快速连续按键，偶尔会觉得字符"挤"了一下。鼠标移动倒是没问题，因为鼠标事件的频率低、数据量小，220ms的延迟在位移控制上体感不明显。
这个结果也验证了一个判断：Serverless信令层适合键鼠这类小数据量、低频率的控制指令，但绝对不适合传屏幕画面或语音流。远程画面传输的视频流需要的是持续性高带宽连接，和Serverless按请求计费的模式完全不在一个设计方向。
6.3 稳定性复盘与优化
100次连续按键事件里，公网路径出现了几次微小的乱序和一次连接闪断。排查后定位到两个原因：
- WebSocket心跳间隔太长：云平台默认的WebSocket空闲超时大概是60秒，而我的心跳设置为90秒，导致偶尔触发超时断开。把心跳间隔缩短到25秒后，连接稳定性明显提升。
- 函数实例冷启动：虽然配置了预留并发，但夜间长时间不用时平台偶尔会回收，下一次连接进来触发冷启动。我增加了一个定时心跳的"保温"机制，每隔5分钟模拟一次客户端上线保活，彻底解决了这个问题。
蓝牙直连路径的稳定性最省心，唯一需要注意的是Android系统资源紧张时，蓝牙HID服务可能被系统杀掉。我这边加了一个前台服务加低优先级通知，让系统尽量不回收蓝牙HID注册。
7. 安全设计：控制权限不能裸奔
跨设备控制方案天然带着"远程操作电脑"的敏感性，前文提过绑定流程和Token，这一节专门展开安全边界设计，因为这一块直接决定这套工具能不能从"自用"升级成"敢分享给别人用的工具"。
7.1 连接鉴权与数据加密
所有WebSocket连接强制走WSS（TLS加密）。Token放在连接请求的Header里，而不是URL参数——URL参数可能在网关日志里被记录，Token放Header可以避免日志泄露。
绑定期的配对码是一次性的，过期时间5分钟。无论绑定成功还是失败，配对码都用完即焚。这样做的好处是，即使有人截获了配对码，也没法在配对完成后回放攻击。
7.2 指令白名单与消息格式校验
只允许以下三类消息通过信令函数：
key_event：校验keycode范围0到255，modifier范围0到255mouse_event：校验dx/dy范围-127到127，wheel范围-127到127，button范围0到7heartbeat：只含设备ID和当前时间戳
凡是消息体里出现不合法字段或超出范围的数值，函数直接丢弃，不回包、不转发。这样即使有一天Token泄露，攻击者也注入不了自定义的恶意消息——他只能在键鼠语义里折腾，无法借机执行其他协议的命令。
7.3 设备的解绑与远程禁用
代理程序每一次收到合法消息，都会同步更新本地缓存里的Token。如果用户想解绑某台设备，在手机端发起解绑请求，Serverless把对应设备的Token全部作废，并下发一个"disable"指令给代理程序，代理程序收到后立即断开连接并进入禁用状态。这个功能在我借电脑给别人、临时共享控制权时尤其有用。
我还遇到过一种情况：电脑被重装系统，代理程序本身丢了，但云端还留着旧的设备绑定。为此Serverless端加了一条规则——如果设备超过30天没有发心跳，自动解绑，避免僵尸设备占用设备ID。
8. 高频问题排查：我踩过的几个典型坑
最后整理一份问题排查清单，都是我在不同设备上实测过程中真实踩过的坑，按出现频率排序。
| 问题现象 | 根因 | 解决方式 |
|---|---|---|
| 手机被电脑识别为"未知蓝牙设备" | SDP_RECORD未正确注册 | 确认使用BluetoothHidDevice.SDP_RECORD并重新注册 |
| Android 12+连接时崩溃 | 缺少BLUETOOTH_CONNECT动态权限 | 运行时申请权限，而不是只在Manifest声明 |
| 键盘输入"重复字符" | 没有发送键抬起事件 | 检查按键释放逻辑，按下后必须清零keycode再发一次报告 |
| macOS代理程序收不到键鼠事件 | 终端没有获得"辅助功能"权限 | 在系统偏好设置中给运行代理的终端App授权 |
| Windows管理员窗口无响应 | 代理程序非管理员权限 | 以管理员身份运行代理程序 |
| 公网延迟突然升高 | 函数实例冷启动 | 配置预留并发，或开启定时心跳保活 |
| 智能电视鼠标无响应 | 电视不支持相对位移鼠标 | 切换为绝对移动报告或仅使用键盘控制 |
| 手机发热明显 | 蓝牙HID + 前台服务持续工作 | 降低鼠标发送频率，或空闲时自动断开蓝牙连接 |
其中"Android 12动态权限"这个坑最有代表性：Android 12之前蓝牙权限在安装时静态授予，App升级到Android 12之后，老的安装包直接崩溃。我自己第一次遇到时排查了很久，最终在系统日志里看到SecurityException才定位到是权限模型变化导致的。
调试过程我强烈建议用抓包工具确认HID报告实际发出的字节。手机上抓不了蓝牙HID数据包，但可以在电脑上用Wireshark配合蓝牙适配器抓HCI层数据，确认手机是否真的在发送期望的报告字节。这个习惯能帮你把问题快速拆成"发送端问题"还是"接收端问题"，避免两端互相猜疑。
9. 几个可以继续扩展的方向
这套基础框架跑通后，后续的想象空间其实挺大，我在做的时候顺手验证了几个方向，给想做扩展的朋友一些参考。
第一种是跨设备剪贴板同步。键鼠指令通道本身就是一条现成的双向数据通道，把"复制/粘贴"语义映射为剪贴板内容同步，手机复制一段文字，直接能在电脑上粘贴，反之亦然。这个功能只需要在协议层增加一个clipboard_sync消息类型，手机端和代理程序各自对接系统剪贴板API即可。
第二种是结合自动化脚本。把手机当成一个"触发器"，在目标电脑上执行预设的脚本序列。比如在手机上点一个按钮，电脑自动打开某个软件、执行一连串操作。这种场景更适合在固定工位上使用，Serverless信令层天然支持多端联动，不需要额外搭建自动化平台。
第三种是让Serverless层只做信令，不做业务逻辑。如果你有多个设备要控制，可以在云端再接一个"控制策略服务"，它负责判断一条键鼠指令该转发给哪台设备、是否允许在某个时间段内使用，从而把权限控制做得更细。
这几个方向本质上没有改变架构，都是在现有消息协议里加消息类型、在信令函数里加路由规则。这也是这套方案最让我满意的地方——架构简单，但扩展面很宽。
回到最初的需求——临时需要控制一台电脑，又不想被线缆和场地束缚。这套"蓝牙HID + Serverless信令"的组合，到目前为止是我用过的最优解。近场不装任何软件，远程不需要自建服务器，一套代码同时覆盖两种场景。如果你也想做类似的东西，我的建议是先跑通近场蓝牙HID，因为那一步可以让你快速看到"手机变成键鼠"的即时反馈，有了这个正向激励，再往远程层加Serverless信令，整个过程会顺畅很多。
