蓝牙小程序开发方案

很多团队第一次评估蓝牙小程序开发，先想到的往往是免安装、扫码即用，觉得它比原生 APP 更轻，首期也更容易上线。真到项目往前推，进度卡住的地方通常不在页面数量，而在设备链路、微信限制、样机状态和现场联调条件有没有先谈实。前面说得含糊，后面返工就会堆到连接、控制和验收阶段。

如果项目还在立项前，建议先把设备类型、目标用户、主要操作、样机现状和计划上线时间整理出来，再对照蓝牙小程序开发、蓝牙APP开发服务和蓝牙小程序近场控制案例看看这次更接近哪种交付方式。这比一开始就讨论页面多少、风格怎么做更有用。资料暂时不全也没关系，可以先通过联系我们说明当前设备情况，把首期范围先收住。

先把小程序边界定清

蓝牙小程序最怕入口和交互边界含糊。扫码进入还是搜索进入，首次连接是否需要校验，断连后怎么提示，蓝牙没开或权限被拒时怎样引导，状态回读和异常重试做到哪一层，这些问题开发前说实，联调时才不容易来回推翻。

设备资料也尽量一次补齐。广播规则、服务和特征值、指令格式、状态字段、异常码、版本差异、测试样机说明，这些内容越完整，项目越容易按排期推进。很多延期并不是代码难写，而是协议没写全，或者不同批次样机表现不一致。后面如果还计划接后台、账号体系或远程能力，也建议顺手看看常见问题里的交付边界，把首期和后续版本先分开。

立项时最好先确认这几件事。

设备发现、绑定、控制、重连和解绑的完整流程
关键指令、状态回传和异常提示的字段定义
测试样机、固件版本和日志抓取方式
首期是否只做近场控制，还是还要接业务后台

预算判断也该在这一步完成。只做设备发现、绑定、控制和基础提示的近场工具，和同时要接账号、日志、后台、安装回执、故障诊断的小程序，成本不会落在同一档。设备型号越多、样机越不稳定、微信侧限制越复杂，开发和联调时间通常就越长。很多团队会把“小程序更轻”直接理解成“项目更便宜”，真正拉开报价的还是设备链路和现场条件。

首期范围收得住，排期才会稳

蓝牙小程序首期更适合先做一个能上线、能验收、也方便后续复用的基础版本。找到设备、完成绑定、查看状态、下发主要指令，再把结果反馈给现场用户，第一版通常就具备交付基础。要是首版同时把商城、会员、报表、工单、经销商分级、远程配置一起塞进去，近场控制还没跑顺，外围系统已经先把节奏拖散。

还要尽早判断它更像工具型入口，还是业务型入口。工具型项目更看重连接速度、操作反馈、异常提示和现场可用性；业务型项目通常还会牵涉账号、组织、日志、权限和后台配置。两类项目的排期、验收方式和资料准备差别很大。若后面还计划扩成完整设备平台，可以把物联网APP开发服务和 IoT定制开发服务一起对照，先想清楚小程序在整套方案里承担什么角色。

比较稳妥的排法，通常是把版本顺序拉开。

首期先完成设备接入和核心控制场景
二期再补账号、消息、日志和后台配置
需要持续运营时，再扩更多设备型号和业务流程

这样安排的好处很直接，联调问题不会和外围功能搅在一起，验收标准也更容易写实。另一个常被忽略的问题，是这套小程序究竟给谁用。安装人员、售后人员、渠道人员和终端用户关注点完全不同。首期角色没定住，页面上看着只是多几个入口，落到交付时往往会变成每一类人都觉得还差一点。

如果正在比较服务商，也可以先看对方会不会主动追问微信限制、样机稳定性、首期角色和现场使用链路。愿意先帮项目缩边界、收条件的团队，通常更清楚这类项目怎样落地。

小程序和 App 共用一套代码

BMS 项目的微信小程序和 App 用同一套 uni-app 代码，小程序端同样能蓝牙直连电池、查看电芯电压和做 OTA。小程序的蓝牙接口和 App 有差异，所以升级日志单独为小程序记了一份。后来客户要给不同的 PACK 厂各开一个小程序，平台就按 PACK 厂分别配置首页 Banner、登录方式和协议页面，小程序端只保留微信登录。参考BMS 云平台与多端 App 案例。

小程序蓝牙接口的调用顺序

微信小程序蓝牙接口调用顺序时序图

小程序蓝牙开发的骨架就是上图这十来个接口，难点在于每一步都可能失败：用户没开系统蓝牙、拒绝授权、设备被别的手机连着、连接超时……每个失败分支都要给出明确的提示和下一步操作，否则用户只会看到「连不上」。

写入分包和节奏控制

官方建议单次写入不超过 20 字节，超过的数据要自行分包，连续写入之间还要控制节奏：

// 小程序分包写入：每包 20 字节，串行发送
async function writeChunks(deviceId, serviceId, characteristicId, buffer) {
  const CHUNK = 20
  for (let offset = 0; offset < buffer.byteLength; offset += CHUNK) {
    const value = buffer.slice(offset, Math.min(offset + CHUNK, buffer.byteLength))
    await new Promise((resolve, reject) =>
      wx.writeBLECharacteristicValue({ deviceId, serviceId, characteristicId, value, success: resolve, fail: reject })
    )
  }
}

Android 上可以调用 wx.setBLEMTU 请求更大的 MTU 来减少分包次数，但要以协商结果为准，并保留 20 字节的兼容路径。

小程序蓝牙与 App 蓝牙的差异

小程序蓝牙与 App 蓝牙的差异对比

据此划分功能：扫码绑定、查看状态、简单设置放小程序，扫码即用；诊断、批量操作、长时间 OTA、离线记录更适合放 App。我们的 BMS 项目两端都做了，小程序端同样能蓝牙直连电池和做 OTA，升级日志单独为小程序记录一份，方便和 App 对比排查。

共用代码时的蓝牙适配层

用 uni-app 可以让小程序和 App 共用业务代码和协议解析，差异集中在蓝牙适配层：

蓝牙 API 在两端基本一致，但 MTU、后台、权限行为不同，适配层分别处理；
页面层用条件编译处理少量平台差异；
协议编解码、数据模型完全共用，保证两端数值一致。

现场细节会直接决定体验

蓝牙小程序能跑出演示流程，不代表已经具备交付条件。真到现场，用户先感受到的是扫描够不够快，连接断开后会不会卡住，状态刷新是否及时，按钮按下去有没有明确反馈，权限没开时提示是否清楚。这些细节处理得粗糙，功能表再完整，体验也会立刻掉下来。

测试时不要只跑顺畅路径。蓝牙关闭、权限拒绝、设备离线、前后台切换、弱信号环境、多台设备切换、固件版本不一致，这些情况都值得提前走一遍。问题越早暴露，后面返工越少。项目若已经有样机和协议资料，可以直接通过联系我们说明当前设备情况、首期目标和上线时间，我们会按接入链路、交付范围和联调条件给出更贴近实际的小程序方案建议；准备推进立项，也可以直接留言“获取小程序方案”。

这类项目通常更适合这几种场景。

需要做设备扫码安装、近场控制或售后诊断的小程序项目
想先用微信入口验证首期可交付版本，再决定是否扩完整 APP
安装、交付或售后人员主要在现场使用，希望降低上手门槛
设备还在迭代，想先把近场控制流程做稳

立项资料也建议同步准备好。

设备样机、广播规则、特征值、指令格式和状态字段
微信侧限制、扫码入口、授权流程和异常提示要求
首期用户是谁，主要操作链路有哪些，是否只做近场控制
是否需要安装回执、售后记录、后台协同或后续扩 APP
计划上线时间、测试机型和现场联调安排

很多团队最后都会问三个问题。蓝牙小程序和蓝牙 APP 怎么选，关键看首期重点是不是免安装、现场扫码、近场控制或售后工具；如果后面还要长期在线、复杂账号、多角色协同或更完整的平台能力，通常更适合直接做 APP，或者一开始就把两阶段方案排好。开发周期一般多久，要回到样机稳定度、协议完整度和首期范围来判断，样机稳定、协议清楚、首期只做近场控制基础版本时，四到八周更容易收住；若还要接后台、账号、批量安装或售后流程，周期通常会继续往后拉。首期验收最该看什么，重点还是扫描、连接、控制、状态刷新、异常提示和现场可用性，设备离线、权限拒绝、蓝牙关闭和多台设备切换这些场景，最好都提前写进验收清单。

常见问题

微信小程序能连接蓝牙设备吗？

可以，微信提供了完整的低功耗蓝牙接口，支持扫描、连接、读写特征值和接收通知，适合扫码绑定、查看状态和简单控制等场景。

小程序蓝牙每次能写多少字节？

官方建议单次写入不超过 20 字节，超过的数据需要分包串行写入。Android 可以尝试协商更大的 MTU，但要保留兼容路径。

小程序蓝牙切到后台会断开吗？

小程序切到后台后连接可能被中断或受限，OTA 等长流程要提示用户保持前台、防止息屏，并支持中断后重新开始或续传。

小程序蓝牙获取到的 deviceId 是 MAC 地址吗？

Android 上通常是 MAC 地址，iOS 上是系统生成的 UUID。需要稳定识别设备时，建议设备在广播名或数据中带上 SN。

小程序能做蓝牙 OTA 吗？

可以，我们的 BMS 小程序就支持蓝牙 OTA。需要分包、逐包确认，并单独记录升级日志，同时处理切后台和息屏带来的中断。