企业官网建设流程全解析

最近帮朋友调试了一个“雷达小程序”的项目，真机跑起来的那一刻，雷达波形在手机屏幕上扫过，确实有点科幻片的意思。但剥开外壳看本质，“雷达小程序”其实就是民用雷达传感器（毫米波、tof、uwb、激光雷达等）与微信小程序搭建的一条数据链路——雷达负责感知物理世界，小程序负责把感知结果变成人能看懂的画面、能操作的交互。干过这行的人都知道，真正的难点从来不在“雷达”三个字上，而在雷达数据怎么采、怎么传、怎么渲染、怎么在小程序里活下来。

这篇东西适合正在做物联网小程序、智能硬件配套应用、室内定位或安防监控的开发者，也适合想把手头雷达模块“塞进”微信生态的产品经理。我会从技术选型讲起，拆解数据链路，用一套室内测距雷达小程序的完整实现作为主线，把蓝牙通信、Canvas渲染、地图叠加这些环节逐个掰开，最后把调试中踩过的坑整理成速查表。全程偏实战，不堆概念，看完能直接落地。

1. 雷达小程序的真实定位：一次“硬件+软件”的握手

1.1 民用雷达传感器都有哪些“亲戚”

很多人一听到“雷达”就联想到军事或者机场塔台，实际上现在能跟小程序打交道的，基本都是民用小雷达，尺寸跟一枚硬币差不多。我按工作原理和适用场景，把常见的分了几类：

• 毫米波雷达：工作在24GHz、60GHz、77GHz频段，测距、测速能力强，受光照灰尘影响小，常用于汽车辅助驾驶、室内人体存在感知、跌倒检测。缺点是小贵，调试需要配专用评估板。
• tof雷达：激光飞行时间测距，响应快、精度可以到厘米级，适合做避障、测距、建图。扫地机器人里那一圈转来转去的，基本就是tof或单线激光。
• uwb雷达：超宽带脉冲雷达，穿透性好、定位精度高，在室内定位、无感考勤、禁区告警上比较火。
• 超声波雷达：严格说不是电磁波雷达，但很多国产模组对外也叫“雷达”，成本极低，倒车雷达、水位检测用得最多。

给小程序做配套，我建议新手优先从tof或毫米波入手。原因很简单：这两种模块的调试工具成熟，串口或蓝牙输出格式规范，网上能找到的协议文档也全。选型这件事，最怕拿到一个只有“用户手册.pdf”却没样例代码的模块，后续全得靠抓波形猜协议，心态容易崩。

1.2 为什么是微信小程序来当雷达的“屏幕”

雷达设备本身没有屏幕，传统做法是电脑连串口看波形，或者用板子自带的小屏看数字。但这两条路都有自己的问题：串口调试意味着人得守在电脑旁边，板子自带的屏幕又做不了复杂交互。小程序的好处在于：

• 零安装，微信扫码即用，硬件厂商不用为每个客户单独配一款App。
• 蓝牙ble与WiFi接口成熟，能和绝大多数物联网雷达模块直接通信。
• 开发者工具链完善，真机调试、远程日志、云开发都有现成方案。
• 分享方便，一个二维码丢到群里，客户自己就能测，这种优势在硬件交付场景里太重要了。

我之前见过一个做安防雷达的厂商，App端开发拖了半年，后来换小程序，两周就上线了内测版。不是小程序功能有多强，而是它天生适合“轻量连接硬件”这个场景。你要做的是雷达的“遥控器+仪表盘”，不是做一个大型数据处理平台，小程序的边界刚刚好。

1.3 技术链路总览：雷达、采集、通信、展示的四层结构

雷达小程序的整体架构，我习惯拆成四层，每一层都有独立的技术选型：

• 感知层：雷达模组负责输出目标数据，常见字段有目标距离、角度、速度、信号强度，有的模组直接输出点云坐标。
• 通信层：蓝牙（ble）、WiFi（TCP/UDP/MQTT）、串口转WiFi模块，负责把数据从雷达搬到手机或服务器。
• 解析层：小程序里对数据帧做解析、校验、滤波，把二进制变成可渲染的对象。
• 展示层：Canvas波形、地图轨迹、三维场景、列表与卡片。

这四层里，最容易被人忽视的是解析层。很多人以为连上蓝牙、拿到数据就够了，结果是原始数据一股脑塞进渲染层，帧率掉到个位数，卡得没法看。雷达数据往往有固定的帧率（10Hz到30Hz），每一个点都要经过CRC校验、坐标换算、单位转换，这些活全堆在小程序主线程里，不卡才怪。

所以我在做设计时定了一条规矩：雷达数据帧的解析必须拆出独立的处理函数，并且优先做数据削减，而不是全量渲染。比如雷达扫描一圈有300个点，很多点是重复的、静止的，可以先做聚类去重，只把有效目标的坐标和速度传给Canvas。这个思路在后文的代码里会体现出来。

2. 核心链路设计与数据流细节

2.1 蓝牙通信选型：ble是默认答案，但要处理好MTU和重连

雷达跟小程序的通信，90%的情况走蓝牙BLE。选BLE不选经典蓝牙，原因很现实：微信小程序不支持经典蓝牙接口，只有wx.openBluetoothAdapter、wx.createBLEConnection这一套BLE API，没有别的选择。

BLE通信有几个坑，我一个个说。

第一，MTU限制。BLE默认的MTU一般是23字节，扣掉3字节协议头，实际能用的只有20字节。如果你的雷达数据帧超过20字节，就必须走分包。我见过一个雷达模块一帧数据48字节，新手直接按一包收，结果收上来的数据永远是碎的。解决办法是在小程序的蓝牙监听回调里做粘包处理：定义一个累积缓冲区，每次收到数据就往里追加，再按帧头帧尾去切。伪代码的思路是：

let buffer = new Uint8Array(); wx.onBLECharacteristicValueChange((res) => { const bytes = new Uint8Array(res.value); // 追加到累积缓冲区 buffer = concat(buffer, bytes); // 通过帧头帧尾循环截取完整帧 while (buffer.length >= FRAME_LEN) { if (buffer[0] === 0xAA && buffer[1] === 0x55) { const frame = buffer.slice(0, FRAME_LEN); handleFrame(frame); buffer = buffer.slice(FRAME_LEN); } else { // 丢弃坏字节 buffer = buffer.slice(1); } } });

第二，断开重连。雷达设备跟手机之间的蓝牙连接，非常容易受干扰，尤其是设备在转动、人在走动、微波炉开着的时候。实测下来，模块跟手机隔一堵墙就可能丢包，隔两堵墙基本失联。所以必须监听wx.onBLEConnectionStateChange，一旦断开立刻提示用户，并且做主动重连。这里有一个经验：重连别太频繁，最多每秒一次，连续五次失败就停止并弹出“请靠近设备”的引导，否则用户会看到手机蓝牙界面一直被占着，体验极差。

第三，一对多雷达的场景。有些环境不止一个雷达，比如仓库四个角落各装一个。这种情况下，BLE这种短距连接就不合适了，建议换WiFi方案：雷达通过ESP32等模块接WiFi，小程序访问局域网接口获取数据，或者雷达端主动把数据通过MQTT推送。小程序里用wx.request拉数据，或者用wx.connectSocket维持一个WebSocket长连接。延迟会比BLE高一点点，但稳定性和多设备并发能力好得多。

2.2 雷达数据帧的解析：字段、校验、坐标系换算

不管什么雷达，数据帧的格式万变不离其宗，通常包含这么几块：

解析的时候最需要注意的是小端与大端。很多国产模块默认输出小端序，而JavaScript的DataView默认是大端读取，写代码的时候如果不指定littleEndian参数，读出来的距离值会差得离谱。我踩过一次，一帧数据解析后距离变成了原本的256倍，排查了很久才发现是端序问题。稳妥做法是统一封装一个读取函数：

function readInt16(buffer, offset) { const view = new DataView(buffer); return view.getInt16(offset, true); // true 表示小端序 }

坐标系换算也是一大坑。雷达输出的“角度”有的是相对雷达正前方的偏角（-45°到+45°），有的是绝对扫描角（0°到360°），还有的是极坐标。在小程序里，Canvas的坐标系是左上角为原点，X轴向右、Y轴向下，和数学坐标系是反着的。所以从雷达拿到（距离r，角度θ）之后，要渲染到屏幕上，得做两步换算：

const rad = (angle * Math.PI) / 180; const x = centerX + r * Math.cos(rad) * scale; const y = centerY - r * Math.sin(rad) * scale; // Y轴取反

这里的scale是像素每米的缩放比。如果雷达范围是6米，屏幕绘图区域是300像素宽，那scale就取25左右。做这个换算之前，先确认雷达的角度单位到底是度还是弧度，我见过不少直接把弧度当度来算的，画出来的点全部挤到一条线上。

2.3 帧率控制与渲染优化：别让数据淹没了界面

雷达数据的感知层帧率通常根据模组性能和场景需求设定：静态测存在1～5Hz就够，动态追踪10Hz以上体验更好，复杂点云场景可达30Hz。而微信小程序里Canvas的刷新率，受设备性能影响，稳定跑到60fps很难，尤其是在低端安卓机上，纹理重绘和Canvas重绘会导致掉帧明显。

我的做法是引入**“节流渲染窗口”**：数据解析照常进行，但渲染不跟着数据频率走，而是固定在每100毫秒取一次最新的完整状态去重绘。也就是数据可以达到20Hz，渲染只跑10fps，中间的帧直接丢弃。用户肉眼看不出来差别，但CPU占用率能降一半。代码上是这样：

lastRenderTime = Date.now(); if (Date.now() - lastRenderTime > 100) { redraw(canvas, latestData); lastRenderTime = Date.now(); }

另外，Canvas绘制时尽量别在每次重绘时新建Path，可以复用同一个Path对象，调ctx.clearRect清屏之后再重新绘制。这样能减少垃圾回收的频次。像雷达这种高频更新的场景，内存抖动是卡顿的主要来源之一。

3. 实操过程：做一个室内测距雷达小程序

3.1 硬件准备与协议约定

我实际用过的是一款国产tof测距雷达，量程6米，扫描角度360°，每秒扫描10圈，输出格式为每帧一个距离值，帧头0xAA 0x55，后面跟着2字节的距离。这种雷达最典型的使用方式是通过串口转BLE模块，在9600波特率下工作，手机通过BLE订阅特征值获取扫描数据。

硬件接线没什么好说的，就是典型的串口转蓝牙模块接线，重点在于供电。雷达模块的峰值电流可以达到200mA，如果用手机供电或劣质USB口供电，电压跌落会导致波形跳跃。我给雷达用的是5V/1A的独立电源，实测波形稳定。如果是电池供电，建议选容量足够的锂电池，并加一个220μF的电容稳压。

协议这块，我的建议是在动手前先和硬件工程师一起定一个清晰版本。我的通信协议示例：

帧头: 0xAA 0x55 数据: 2字节距离（单位mm，小端序） 校验: 1字节异或校验（帧头异或数据）

这条协议简单到不能再简单，但能覆盖90%的测距场景。如果你的雷达是点云雷达，那就把数据定义为“目标数 + 每个目标的距离 + 角度”，帧长会变成几十字节，需要走分包。

3.2 小程序BLE连接的完整代码实现

核心逻辑分三步：初始化蓝牙、扫描设备并连接、订阅特征值并处理数据。

先看初始化与连接部分：

async initBLE() { const adapterOk = await new Promise((resolve) => { wx.openBluetoothAdapter({ success: () => resolve(true), fail: () => resolve(false), }); }); if (!adapterOk) { wx.showToast({ title: '蓝牙初始化失败', icon: 'none' }); return; } wx.startBluetoothDevicesDiscovery({ allowDuplicatesKey: true }); wx.onBluetoothDeviceFound((res) => { const devices = res.devices; const hit = devices.find((d) => d.name === 'TOF-RADAR'); if (hit) { wx.stopBluetoothDevicesDiscovery(); wx.createBLEConnection({ deviceId: hit.deviceId, success: () => { wx.getBLEDeviceServices({ deviceId: hit.deviceId, success: (r) => { const service = r.services.find((s) => s.uuid.indexOf('ffc0') > -1); wx.getBLEDeviceCharacteristics({ deviceId: hit.deviceId, serviceId: service.uuid, success: (res2) => { const char = res2.characteristics.find((c) => c.uuid.indexOf('ffc1') > -1); wx.notifyBLECharacteristicValueChange({ deviceId: hit.deviceId, serviceId: service.uuid, characteristicId: char.uuid, state: true, success: () => this.setupDataListener(), }); }, }); }}); }, }); } }); }

这段代码里有个细节：service和characteristic的UUID，很多低端BLE模块用的还是16位短UUID（比如0xFFC0），wx.getBLEDeviceServices返回的却是完整的128位UUID。如果直接用indexOf('ffc0')做模糊匹配就能命中，但要注意大小写，模块手册里写的是大写FFC0，返回的UUID却是小写，所以统一用toLowerCase()再判断最稳妥。

订阅特征值之后的数据流处理，就是前面提到的粘包+切帧+解析。这一整条链路的代码，可以抽象成模块级的DataFeed类，把蓝牙的原始回调彻底隔离在业务渲染之外。这样后续如果换成WiFi方案，只需要改DataFeed内部实现，UI层完全不用动。

3.3 雷达扫描的可视化：Canvas画雷达扫描线

雷达的经典可视化方式有两种：一种是“扫描线雷达屏”，一条辐射线一圈圈扫，碰到目标就画亮点；另一种是“轨迹图”，把所有历史点的位置画出来。我先说扫描线方案。

新建Canvas，设置宽高为屏幕宽度减去边距，绘制背景。雷达扫描线的核心在于：维护一个当前角度变量，每次重绘时角度递增一个步长，画一条从圆心到边缘的线条，然后在当前角度附近绘制目标点。

const state = { angle: 0, targets: [], // [{ distance: 2500, rssi: -40 }] }; function drawRadar() { ctx.clearRect(0, 0, width, height); drawBackground(ctx); // 画刻度圆、十字线 // 绘制扫描线 state.angle += 2; if (state.angle >= 360) state.angle = 0; const rad = (state.angle * Math.PI) / 180; const scanX = centerX + R * Math.cos(rad); const scanY = centerY + R * Math.sin(rad); ctx.strokeStyle = 'rgba(0, 255, 0, 0.8)'; ctx.lineWidth = 2; ctx.beginPath(); ctx.moveTo(centerX, centerY); ctx.lineTo(scanX, scanY); ctx.stroke(); // 绘制目标 state.targets.forEach((t) => { const point = polarToXY(t.distance * scale, t.angle); ctx.fillStyle = '#00ff00'; ctx.beginPath(); ctx.arc(point.x, point.y, 3, 0, Math.PI * 2); ctx.fill(); }); }

这段代码里常踩的一个坑是Canvas的坐标系翻转。手机屏幕的Y轴向下，而雷达的极坐标Y轴向上。如果你不做Y轴取反，目标会出现在雷达图像的下方——雷达明明在正前方，屏幕上的点却显示在下方，很容易误导用户判断目标方位。这也是为什么我前面专门给了极坐标换算公式，里面带了那个减号而不是加号。

对于目标点比较多的场景，比如雷达的某一帧有30个有效目标，Canvas的drawArc函数在低端机上会拖累帧率。优化手段是改用fillRect代替arc，画一个微型方块代替圆点，性能能提升好几倍。虽然画面没那么圆润，但在手机屏幕上看起来几乎无差别。

3.4 cesium、天地图与3D雷达波的叠加玩法

如果雷达小程序需要展示目标在真实地图上的位置，比如智慧园区或仓储管理场景，可以让雷达数据联动地图应用叠加定位信息。Cesium常用于3D地球场景，作为三维空间引擎，结合雷达点云数据，可以做楼宇级或园区级的三维目标分布。在3D场景里，目标点云可以映射为经纬度坐标，通过计算雷达安装位置的朝向角、俯仰角来完成坐标换算。这套做法的核心逻辑是“雷达局部坐标 → 经纬度全局坐标”，需要三个参数：雷达安装点的经纬度、雷达朝向的方位角、目标相对于雷达的极坐标。换算公式大概是这样：

// 把极坐标转为局部直角坐标 const localX = distance * Math.sin(angle); const localY = distance * Math.cos(angle); // 再通过方位角旋转 const rotatedX = localX * Math.cos(bearing) - localY * Math.sin(bearing); const rotatedY = localX * Math.sin(bearing) + localY * Math.cos(bearing); // 最后做经纬度偏移 const deltaLng = rotatedX / (111320 * Math.cos(lat)); const deltaLat = rotatedY / 110540;

光是把目标画在地图上还不够，很多监控场景需要展示雷达的扫描范围和波束覆盖区域。在2D地图里可以画一个扇形表示波束角，比如60°波束角、50米半径的扇形区域。在三维场景中除了扇形，还可以引入“雷达波罩”效果：一个半透明的半球罩盖在雷达位置上方，让观察者对覆盖范围一目了然。

天地图与微信小程序的集成也是这个逻辑：用天地图作为底图，把雷达目标、报警事件、巡逻轨迹叠加到“图层组”上。天地图有官方的小程序适配流程，配置好密钥后，转发WebService请求即可。国内项目用它做底图，好处是符合地图审批规范，不会因为用了国外地图服务被卡审核。

3.5 uniapp打包与多端适配的经验

不少团队会选uniapp来加快开发速度。uniapp的好处是一套代码可以编译成微信小程序、H5、App，但坏处也明显：它对蓝牙API的封装不够彻底，部分接口需要条件编译。

我在uniapp项目里同时使用微信原生的wx.onBLECharacteristicValueChange和uniapp的uni.onBLECharacteristicValueChange，但最好是直接以微信API为准，因为uniapp在部分版本里对ArrayBuffer的真实性处理有bug。另外，uniapp的Canvas组件跟原生小程序的Canvas接口存在差异，如果要做高频重绘的雷达屏，建议直接使用uni.createCanvasContext，并手动指定type为2d。记住一个原则：uniapp适合偏逻辑的业务界面，雷达这种依赖底层绘制的功能，尽量不要过度依赖跨端框架封装，关键渲染步骤用条件编译走原生逻辑。

打包时还有几个容易被忽略的点：小程序的蓝牙权限需要在app.json里声明permission字段，否则iOS审核会直接打回；如果涉及定位和地图，还需要配置requiredPrivateInfos说明用途。这些配置项在开发工具里不会报错，但一到真机或提审就出问题。

4. 调试与问题排查技巧实录

4.1 用Charles/Proxypin抓包排查小程序网络问题

雷达小程序除了蓝牙，常常还要上报数据到服务器，比如目标轨迹、报警记录。这种时候，如果发现数据对不上，或者上报失败，我一般先用抓包工具看看请求链路。

Charles是mac/Windows都常用的HTTP调试工具，配置好之后，手机设置HTTP代理指向电脑IP，就能看到小程序的每一个网络请求。Proxypin则是PC端的抓包工具，轻量、界面简单，适合快速查看小程序发出的请求和响应。实际使用中，我一般这么操作：

1. 确保手机和电脑在同一个局域网。
2. 电脑打开抓包工具，启用SSL代理，并安装信任证书。
3. 手机WiFi设置里填上电脑IP和代理端口。
4. 打开小程序的“开发调试”模式（依赖微信开发者工具与手机联动）。
5. 操作小程序触发网络请求，抓包工具里筛选出关键域名，看请求参数、响应码、耗时。

抓包的目的主要是确认：小程序请求是否如期发出，参数格式对不对，后端返回是否符合预期。我遇到过的情况是，后端同学返回的JSON里有一个字段类型从number变成了string，前端没做类型兼容，导致渲染出来的距离变成“--”。抓包一眼就看到了，省去大量联调时间。

这里要注意一个合规问题：抓包调试只用于自己开发和测试环境，不要对线上环境做拦截，更不能用抓包工具去解析第三方小程序的敏感数据。这是基本的职业边界。

4.2 真机调试的常见问题：蓝牙、开发者工具、真机权限

用微信开发者工具跑雷达小程序，跟真机跑完全是两回事。开发者工具里没有蓝牙硬件，只能靠模拟蓝牙API，你得手动mock数据帧。我一般会在工具里写一个假的DataFeed，用定时器模拟雷达数据，这样UI开发可以不依赖硬件。

真机调试时最常遇到的是这个问题：蓝牙能扫描到设备，但连接一直失败。排查思路按优先级排序：

• 检查是否在app.json里声明了蓝牙权限（尤其是Android 12以上，需要动态申请定位权限）。
• 确认雷达模块是否支持BLE，而不是BLE和经典蓝牙双模中的经典模式。
• 看WiFi是否关闭了（一部分BLE模块跟WiFi共存时信道冲突，断开WiFi后能连上）。
• 重启手机蓝牙，有时候手机蓝牙缓存了旧设备信息，会导致连接失败。

另外一个跟安卓真机相关的坑：扫描回调里拿到的deviceId是变化的，有的手机会在每次扫描时为同一个设备生成不同的deviceId。所以连接时不能用“上一次缓存”的deviceId直接连，要重新扫描，用广播里的name或mac字段做精确匹配。

4.3 常见问题速查表

我把高频问题整理成了表格，方便现场排查：

5. 雷达小程序的延伸场景

5.1 智能家居与安防：存在感知、跌倒检测、报警联动

这是雷达小程序目前落地最多的方向。毫米波雷达可以做到在不采集图像、不暴露隐私的前提下感知人体存在与微动，放在卧室、卫生间里做跌倒检测。小程序端只负责展示感知结果：有人/无人、静止/移动、单位时间内的活动量曲线。

这类应用对实时性要求不算高，1Hz的刷新率就够。真正的关键是误报率。雷达的原始输出经常会把窗帘晃动、宠物走动误判为人，所以小程序端不能只做显示，还需要有限状态机逻辑：连续两帧检测到“人体存在”才切换为占用状态；需要连续空闲超过30秒才切换为无人状态。这类业务逻辑写在前端是可以的，但更稳妥的做法是放在云端规则引擎里，小程序只承担展示与告警推送。

5.2 智慧零售：智能名片、导购雷达、商城导流

很多商场、展会、门店会用“雷达小程序”做客流感知和人机互动。比如一个安放在展位前的雷达，检测到有人走近，小程序自动弹出产品介绍和名片二维码。这个场景催生了很多成套源码，就是热词里看到的“AI雷达智能名片营销利器小程序源码”。

跟硬核的测距雷达不同，这类雷达通常用uwb或毫米波做区域存在感知，灵敏度高，能做到“人一到跟前就触发”。小程序端用不到Canvas波形，核心交互是：雷达触发 → 小程序唤醒 → 展示名片/优惠券 → 引导进商城。本质上是把雷达当一个客观存在的“触发器”，整个体验链路的关键在触发阈值设置和防抖。我实测下来，阈值设在距离传感器1.5米内连续存在5秒以上再触发，体验最好，不然人只是路过就会收到一堆弹窗，很招人烦。

5.3 室内定位与机器人远程监看

nav2导航使用3D雷达的机器人，需要在场端部署雷达定位基站，机器人实时上传位置到后台。小程序可以用天地图或自建平面图叠加机器人位置、路径和雷达覆盖范围。Cesium的三维场景里还能展示机器人的朝向、速度、避障状态。

这类项目的复杂度比前两个高一个量级，因为涉及后端实时推送。小程序的WebSocket在切后台时会挂起，所以设计上不要指望小程序做7x24小时监控，而是把重点放在“拉起时看实时状态，退出后收告警推送”。这也是微信小程序的能力边界，想要持久的后台连接，还是得靠服务号模板消息配合，这是现阶段的现实方案。

5.4 关于雷达小程序，我个人最深的体会

做雷达小程序这段时间，我最直观的感受是：雷达本身的信号处理算法决定上限，但小程序端的数据工程决定体验。一个雷达模块可能只卖几十块钱，但你要是能把它的数据流畅地渲染到手机屏幕，并且稳定跑上几个月，这门手艺在行业里就值钱了。

如果你正打算做类似的东西，我的建议是分三步走：先买一个带官方例程的雷达开发板，用串口助手确认原始数据完全没问题，再进入小程序端的开发。不要一上来就同时调硬件和软件，两头烧钱，又两头看不到结果。进入小程序开发后，也先别急着画好看的界面，把蓝牙连接和数据帧解析跑通，一个数字能稳定实时变化，就算成功了一半。

还有个扩展方向值得留个心眼：现在不少雷达模组开始支持边缘AI计算，可以直接在模块端完成人员计数、轨迹跟踪。这会给小程序省下很多事，因为前端收到的就不再是海量点云，而是“编号+坐标+活动状态”的高层语义数据。我拿一款带AI的毫米波模组试过，数据格式干净得让人感动，丢给小程序后基本零解析成本。

如果你现在是在帮客户做方案选型，我多说一句：明确好“谁来处理雷达原始数据”再动工。模组支持边缘计算的，就选“雷达端出结果、小程序只展示”的架构；模组只输出原始数据的，你就得在云端或小程序端补一层处理逻辑，这部分的研发成本心里要有数。

最后分享一个小技巧，真机调试雷达小程序时，微信开发者工具里的“追踪真机日志”功能一定要开。蓝牙连接失败、数据帧解析报错，这些运行时错误都能在工具里直接看到具体堆栈，比自己在代码里加log高效得多。配合上“性能面板”的帧率监控，一次调试基本能把卡顿和报错一起揪出来。雷达小程序这条路，说难也不算难，但每一步都是实打实的细节，希望这篇东西能帮你少踩几个坑。