蓝牙音箱设计联调与故障排查：从能响到稳定量产

蓝牙音箱项目走到“能响”这个阶段相对容易，真正难的是配对稳定、播放不卡顿、通话切换正常、距离不缩水、量产一致性好。这次接着蓝牙音箱项目设计推进到第 45 个节点，不聊空泛概念，直接把蓝牙传输链路、音频回放链路、电源与射频的相互影响、联调验证方法拆开来讲。如果你手头的板子也出现“手机搜不到设备”“音乐播放断断续续”“删除设备后重新配对失败”“通话切回音乐后无声”之类的问题，这一篇值得收藏。

这篇文章适合正在做蓝牙音箱硬件设计、嵌入式软件调试或产品验证的工程师阅读，也适合想要把一套蓝牙音频方案从样板调成稳定小批量产品的团队。内容会覆盖蓝牙协议选型、几种主流蓝牙芯片方案的方向、硬件设计节点、SDK/协议栈编程思路、联调测试流程、抓包分析工具、常见故障排查方法，以及项目进入量产前必须观察的性能和合规项。由于手上具体型号和实测数据未在标题素材中给出，凡是涉及芯片参数、实测占用、协议栈具体接口的地方，我会明确标注为“按实际 SDK/芯片规格书调整”。

1. 蓝牙音箱项目核心能力速览

在做任何电路细节之前，先明确这个阶段需要关注的能力维度，避免一上来就陷进某个模块的原理图里。下表是蓝牙音箱项目设计过程中最常见的工程关注点，适合作为方案评审和硬件自检清单。

这个表并不对应某一颗具体芯片，而是蓝牙音箱设计时相对通用的检查框架。实际项目会因为主控选择不同而差异很大：有的用双芯片架构，一颗 MCU 做控制、一颗蓝牙音频 SoC 负责音频；有的用单芯片集成了 MCU、DSP、射频前端。先判断自己属于哪一种架构，再去排查问题会快很多。

从系列推进角度看，这一期重点不是“选哪颗芯片性价比最高”，而是“芯片选定之后，如何把蓝牙音频链路做稳定”。产品做到第 45 个迭代阶段，说明前期原理和基础通信已经打通，现在的核心矛盾往往集中在射频环境干扰、协议状态管理、电源纹波对模拟音频的影响这几类问题上。

2. 蓝牙音箱为什么难调试：多条链路互相耦合

蓝牙音箱和普通的有源音箱设计思路不完全一样。普通音箱只需要关心音频输入、功放、喇叭和电源之间的匹配。蓝牙音箱多了一个复杂的无线传输环节，音频数据要经过编码、发射、接收、解码、DAC、功放再到喇叭，每一步都影响最终听感。

第一层链路是射频。蓝牙工作频段在 2.4GHz，和 WiFi、无线鼠标、微波炉都在同一个频段里。音箱结构经常是密闭腔体，天线如果被大面积金属件遮挡或被电池、喇叭磁铁包围，距离和稳定性会明显下降。很多“只有 2 米就断连”的板子，问题往往不在蓝牙芯片本身，而在天线匹配和外壳内部环境。

第二层链路是协议栈。蓝牙音箱播放音乐时最常用的是 A2DP Profile，负责把高音质音频数据从手机发送到音箱；通话时则切到 HFP，音频走 SCO/eSCO 通道。这两个 Profile 的切换逻辑、音量同步、编解码格式协商，都有一整套状态机。手机先连上音箱但不出声，常见原因是 A2DP 没有正确连接，或是协议栈只完成了 ACL 连接却没有建立音频流。

第三层链路是模拟音频。蓝牙芯片送出来的模拟信号非常微弱，如果 DCDC 开关频率干扰、地线回流不合理、功放开启瞬间电压跌落，就会在喇叭里听到底噪、滋滋声或爆音。这些干扰在单独测试蓝牙芯片时不存在，只有整机联调时才出现。

实际调试时最容易犯的错误是只盯着一层排查。射频问题去改软件参数，协议问题去换功放，往往耽误时间。建议先从系统架构上分清链路节点，再按信号流向逐段验证，下文会给出具体的定位方法。

3. 蓝牙协议选型：BR/EDR、BLE 与音频 Profile

这一节用于回答选型阶段最常出现的疑问：蓝牙音频到底走经典蓝牙还是低功耗蓝牙？BR/EDR 和 BLE 有什么区别？为什么 Mesh、Beacon、App 控制这些功能在音箱方案里经常分开实现？

先明确蓝牙协议的基本分工。BR/EDR（Basic Rate/Enhanced Data Rate）就是常说的经典蓝牙，适合连续传输中等速率的数据，比如 A2DP 音乐流、HFP 语音流。BLE（Bluetooth Low Energy）则更强调低功耗和短数据包通信，常用于设备配对、状态上报、远程控制，但承载持续音频流的能力有限。所以蓝牙音箱的主音频通道，成熟方案基本都是走经典蓝牙 A2DP，BLE 通常承担电池电量、EQ 切换、固件升级、辅助配对等功能。

一个容易混淆的点是“蓝牙 4.0 之后支持双模”。双模芯片可以同时跑 BR/EDR 和 BLE，但依然要区分当前链路是经典蓝牙连接还是低功耗蓝牙连接。手机系统里看到的“蓝牙设置界面”只是总开关，具体音箱在音频上使用 A2DP，在电量上报上使用 GATT Service，两者走的是不同协议通道。不能因为手机已经连接成功就默认 A2DP 正常，要分别验证。

音箱方案中常用的 Profile 大致如下表所示。

如果在方案评审阶段需要做一个选型表，建议从传输类型、承载数据、协议栈复杂度、功耗、常见芯片/模组方向几个维度来权衡。比如某国产蓝牙音频芯片厂商，像杰理这类方案在低成本和集成度上就有明显优势，适合重视 BOM 成本的消费类音箱；而一些偏物联网控制的板子会倾向用双模 MCU 配合外部蓝牙音频 Codec。不要单纯用“哪个芯片火”来选型，要看自己的产品形态。

这一阶段的另一个判断点是：如果产品希望支持“手机 App 控制”而不只是传统按键和协议栈控制，BLE 通道会比经典蓝牙 SPP 更合适。尤其现在 App Store 和 Android 权限限制对经典蓝牙更加严格，BLE 的配对和后台连接体验更平滑。音箱可以先维持经典蓝牙 A2DP 播放音频，再让 BLE 专门处理 App 下发指令、EQ 切换、固件升级。两块链路在协议栈内部相互独立，调试时也方便隔离问题。

4. 硬件设计阶段的关键节点

从项目整体看，硬件部分是音箱设计的骨架。蓝牙连接稳定性、音频底噪、待机功耗、充电安全等问题，都会在 PCB 布局和电源设计阶段埋下隐患。下面按模块拆开讲，建议对照自己项目的原理图和 PCB 逐项过。

4.1 电源与供电架构

蓝牙音箱绝大多数使用锂电池，常见的供电需求有两路：一路给蓝牙 SoC、Flash、传感器等数字电路供电，典型电压在 1.8V 到 3.3V；另一路给功放和模拟音频电路供电，功放电压经常高于系统电压，比如 5V 或 12V。使用 DCDC 升压给功放供电时，要重点关注开关频率是否落在音频频带内，以及输出纹波会不会窜入蓝牙芯片的 AVDD 管脚。

PCB 布局上，建议把 DCDC、充电 IC、功放这些大电流开关器件和蓝牙芯片、天线区域拉开距离。地平面尽量保持完整，模拟地和数字地在 ADC/DAC 附近单点连接，避免高频噪声通过地平面耦合到模拟音频参考地。样机阶段可以用 LDO 给模拟部分单独供电，再用示波器对比 LDO 前后的音频底噪差异。

4.2 音频通路与功放匹配

蓝牙音频 SoC 的输出通常有两种方式：I2S 数字输出和模拟 Line Out。前者需要外接音频 Codec 或数字功放，后者可以直接驱动功放芯片。如果使用内置 Codec 的蓝牙芯片，仍然要留意输出阻抗、直流偏置、串音和输出耦合电容。

功放选型要看喇叭阻抗、额定功率、腔体体积和期望最大声压级。D 类功放效率高、发热低，是便携音箱的主流趋势，但也更容易引入高频开关噪声。注意功放输入端到蓝牙芯片输出的布线距离，尽量短，减少 USB 或电源线带来的二次辐射。音箱腔体共振频率、倒相管长度这些声学参数本来由声学工程师负责，但硬件工程师最好知道喇叭阻抗和功放功率的关系，验证时用额定功率 1/8 或 1/3 的音频信号跑长稳测试，而不是一直用满功率连续测试。

4.3 蓝牙天线与射频布局

蓝牙天线的“净空区”非常关键。PCB 天线下方所有层都不要铺铜，天线周围也不能放金属外壳、螺丝、麦克风金属网罩这类导体。低频天线对周边环境更敏感，天线效率往往不是只看反射损耗 S11，而是要看实际辐射效率。样板阶段可以用矢量网络分析仪测 S11，但最终整机性能一定要在完整装配状态下做自由场距离测试。

屏蔽设计方面，如果结构空间允许，尽量给蓝牙 SoC 和射频匹配网络做金属屏蔽罩，避免功放 D 类开关噪声耦合到射频前端。如果空间不够，至少保证音频走线和射频走线之间有明显的地隔离，不要平行长距离走线。匹配网络通常预留 π 型匹配位置，方便天线调试。

4.4 按键、指示灯、充电与检测电路

音箱上的音量加减、播放暂停、蓝牙配对按键，最好由单片机或独立 IO 去扫描，而不是直接拉在蓝牙 SoC 的唤醒引脚上。因为按键线本身就是一条长天线，容易受到静电和射频干扰。每颗按键都要加 ESD 防护器件，按键走线应尽量走内层，减少与天线之间的耦合。

充电部分要区分“充电管理 IC 放在哪一侧”。如果充电 IC 和蓝牙系统共用同一块板，充电期间 AC 纹波和开关噪声可能影响蓝牙射频指标。测试时要专门测“边充电边放歌”和“充满电拔掉充电线放歌”两种状态的音频底噪差异，很多异常只会在充电状态下出现。

4.5 PCB 与结构评审清单

结合大量蓝牙音箱项目经验，建议所有样板投板前都按下面几条自检：

• 天线区域是否做到净空，形状是否被外壳压缩到模块允许的范围。
• 蓝牙芯片、Flash 和晶振是否靠近，晶振走线是否远离射频匹配线和 DCDC 电感。
• 功放、DCDC 是否与蓝牙芯片分区域布局，散热焊盘是否大面积打过孔。
• I2S、模拟音频线是否包地并有参考平面。
• 充电输入、USB 数据线、蓝牙天线的位置是否互相干扰。
• 按键灯、RGB LED 走线是否容易串入音频地环路。

如果以上硬性问题都能通过，再进入固件和协议栈配置阶段。

5. 固件、SDK 与协议栈工作方式

蓝牙音箱的固件开发，根据方案类型差异很大。一类是使用蓝牙音频 SoC 标准 SDK，例如国产蓝牙芯片厂商提供的 SDK 工程，工作重心在根据规格书配置工程文件、修改 IO、处理按键事件和音频解码参数；另一类是使用 Linux 或 RTOS 平台 + 蓝牙协议栈，例如在嵌入式 Linux 上用 BlueZ 协议栈配合声卡驱动做蓝牙音箱，这类方式更适合做差异化功能和自定义音频处理。两者思路不同，调试方法也不一样。

标准蓝牙音频 SDK 的常见做法是，在工程配置里确定设备名、Class of Device、支持的 Profile、编码格式、提示音路径等。这类 SDK 已经把 A2DP、AVRCP 协议栈封装成库，开发者不直接处理协议包，而是通过回调函数接收 Play/Stop/Volume Change 等事件，再操作音频模块。下面给出一段示意代码，演示播放状态回调的常见结构，具体 API 名称以所用芯片 SDK 为准。

// 伪代码示意：蓝牙音频 SDK 播放事件回调 // 实际函数名、结构体、返回值需按芯片 SDK 调整 static void audio_event_handler(bt_audio_event_t event) { switch (event) { case BT_AVDP_PLAY_START: // 手机端开始播放，打开音频通路 codec_start_playback(); dsp_set_eq_mode(current_eq_index); break; case BT_AVDP_PLAY_STOP: codec_stop_playback(); break; case BT_AVDP_VOLUME_CHANGED: // 手机音量同步到本机衰减器 volume = audio_get_volume(); codec_set_volume(volume); break; case BT_HFP_CALL_START: // 电话呼入/呼出，A2DP 切 SCO codec_route_to_call_path(); break; case BT_HFP_CALL_END: codec_route_to_music_path(); break; default: break; } }

在 Linux 平台开发时，问题表现得更明显：蓝牙配对由 BlueZ 管理，音频播放由 PulseAudio/PipeWire/ALSA 管理，两个子系统经常出现“已经连接但是没有音频路由”的状态。排查思路一般是先用 bluetoothctl 确认设备是否已经 Trust 并连接，再检查 audio profile 是否加载，最后看 sound card 是否被识别为 output 设备。

蓝牙音箱项目设计做到一定阶段，往往还会遇到 A2DP 与 SCO 切换、SCO 回音消除、EQ 参数管理、提示音播放冲突等问题。比如手机播放音乐过程中突然来电，协议栈需要快速把音乐暂停、切到 HFP、打开通话语音通路；挂断后再切回音乐。这个切换过程如果处理不当，会出现双方都听不到声音、或者恢复音乐后卡顿 2 到 3 秒。这些通过事件回调都能观察到，但要确认音频路径是否真的重新路由完成。

固件参数管理也是“设计之 45”必须沉淀的部分。EQ、音量曲线、蓝牙名、提示音序号、功放增益阻尼系数，这些参数不要散落在主代码里。可以定义成配置结构体，放在单独的头文件或 Flash 参数区，统一管理和编译版本对齐。

// 示意：蓝牙音箱音效参数结构体 // 实际参数范围、滤波系数需按所选芯片 DSP 规格调整 typedef struct { uint8_t bt_name[32]; // 蓝牙广播与配对名称 uint8_t eq_mode_count; // EQ 模式数量 int8_t eq_gain[5][3]; // 5 段 EQ，三种模式的增益 uint8_t volume_max; // 最大音量档位 uint8_t default_volume; // 开机默认音量 uint8_t call_volume_gain;// 通话增益补偿 uint8_t tws_role; // TWS 主从角色配置 } audio_cfg_t;

写固件时最容易踩的坑是两个：第一，没有检查回调输入参数的合法性，把空指针传给 DSP 或者把音量值减到负值；第二，把阻塞延时放在音频回调线程里，导致蓝牙数据缓冲溢出。特别是在做按键消抖、Flash 写入、LED 呼吸效果时，不要让这些逻辑堵塞音频数据流。

6. 联调测试与功能验证流程

拿到打样回板后，不要急着连手机放歌。可以先按模块上电，做最低限度验证，再逐步打开功能。测试最好有日志输出，并记录每一次的状态转换记录。

建议的联调测试顺序如下：

第一步，确认电源。接上稳压电源或锂电池，不上电先用万用表检查电源对地阻抗是否有明显短路。上电后看电流是否在预期范围，如果电流突然异常，优先检查功放、充电 IC、蓝牙 SoC 的供电是否正常。使用稳压电源时尽量模拟锂电池的内阻特性，直接接台式电源和接电池的测试结果有时候差异很大。

第二步，烧录最小固件，验证串口日志、IO 扫描、Flash 读写。此时不要接功放，避免功放噪声干扰判断。如果芯片支持 AT 指令或厂商调试命令，可以先通过 UART 查看蓝牙协议栈版本、MAC 地址和射频初始化结果。

第三步，开启蓝牙广播或可发现模式，用手机搜索。记录搜索到设备的时间、信号强度、设备名是否正确。如果搜索不到，先看蓝牙芯片是否进入可发现模式，再看天线装配和外壳阻尼。

第四步，配对并连接 A2DP。手机播放歌曲后，确认音箱有声音输出，同时观察播放过程是否出现卡顿。不同手机协议栈差异很大，测试时要覆盖 iOS、Android 新老版本，至少选择 3 到 5 台手机。播放测试曲目建议包含低音密集、人声、高动态范围的片段，用来判断音频链路的失真与限幅。

第五步，测试通话与 A2DP/SCO 切换。手机连接音箱后拨打或接听电话，需要确认音乐暂停、通话声音正常、对方能听到本地麦克风声音、挂断后能恢复音乐。如果在恢复音乐后没有声音，大概率是音频路由没有切回去，需要检查 SDK 的 Call End 处理或者后台应用占用问题。

第六步，测试音量同步与媒体控制。使用手机侧音量键和音箱侧按键，确认两端音量同步方向一致，不存在一方调大另一方调小的问题。AVRCP Profile 是否正常可以通过切歌、暂停、播放等操作判断。

第七步，测试断电重连、回连和低电运行。模拟主机断开蓝牙、关机再开机、清空配对记录重新配对，看是否能快速恢复。回连时间是一个重要体验指标，回连失败次数要计入稳定性测试结果。

下面是一份适合项目组使用的测试矩阵示意，实际字段可以根据产品定义再扩展。

7. 调试工具、抓包与协议分析方法

蓝牙问题之所以比普通串口问题难排查，是因为无线链路不可见，协议栈状态不透明。建议把调试工具按层次准备好，才能在联调时准确缩小范围。

第一类工具分析射频与协议包。普通开发电脑不能直接抓取蓝牙 A2DP 数据包，需要准备一个能够抓取蓝牙 HCI 或空口数据包的设备。Android 系统自带 Bluetooth HCI Snoop Log 功能，开启后可以抓取手机侧蓝牙协议栈收发的日志，再通过 adb 拉取。Linux 平台也可以通过 btmon 等工具抓取 HCI 流量。这些数据适合分析“连接是否建立”“Profile 是否成功”“断开原因是什么”。

第二类工具用于音频链路的验证。手边有一台示波器、万用表、音频分析仪或普通声卡就能完成大部分判断。通过示波器观察功放输出波形，区分破音、削波、开关噪声和直流偏置。如果没有专业音频分析仪，可以用录音笔在固定距离、固定声压下录制播放片段，对比不同版本固件的音频输出。

第三类工具用于调试串口或 SPP 通路。如果蓝牙音箱方案预留了 SPP 或厂商 AT 指令调试口，可以用手机上常见的“蓝牙串口调试助手”连接设备，直接观察模块发送过来的调试信息。这样一来，硬件工程师可以通过 SPP 通道实时查看按键事件、连接状态、协议栈版本，方便快速验证功能是否触发。

第四类工具用于 BLE 相关功能验证。如果音箱有配套 App，或者需要检查 BLE 电量上报、固件升级服务，可以使用厂商调试 App 或通用抓包工具。Python 环境下的 bleak 库提供了一套简单、可控的开发接口，能够扫描并连接 BLE 设备，快捷读取 GATT Service 和 Characteristic。以下代码只是用于联调时的协议观察，不涉及具体量产固件。

# 示例：使用 bleak 扫描 BLE 设备，观察音箱 BLE 广播 # 需要先安装依赖：pip install bleak import asyncio from bleak import BleakScanner async def main(): print("开始扫描 BLE 设备...") devices = await BleakScanner.discover(timeout=10) for d in devices: # 只打印出广播名称包含目标关键词的设备，便于过滤 if d.name: print(f"name={d.name}, addr={d.address}, rssi={d.rssi}") if __name__ == "__main__": asyncio.run(main())

很多工程师看到抓包软件就头疼，总希望一步到“问题原因”。实际上抓包的价值是确认协议栈在什么事件上停顿、出错或拒绝。比如发现 A2DP 没有连接成功，可以先看 ACL 连接是否断开，再看对方是否在监听正确的 UUID。抓包数据要和固件日志互相印证，两类信息缺一不可。

8. 常见问题与排查方法

蓝牙音箱联调和量产初期，大部分问题都可以归入下面几类。把问题和原因、排查方式列成对照，能帮团队快速定位。

这些问题是项目从“样板能响”走向“可稳定量产”的必经门槛。不要指望一次修改解决所有问题，最好的方式是建立一套问题挂账清单，把每条异常现象的环境、器材、固件版本、日志一并记录。否则修完一个又冒出一个，团队对问题是否根治心里没有底。

9. 关键性能观察、功耗与合规安全

蓝牙音箱的性能观察不能只停留在功能层。要看看整个系统在不同负载下的功耗，以及射频是否满足当地法规要求。

功耗方面建议测四类状态：关机漏电流、待机并可发现状态、连接但静音状态、最大音量播放状态。关机漏电流是最容易被忽略却最影响消费者体验的参数，如果喇叭音箱关机后电池两天就没电，大概率是功放没有完全关断、电源按键长按逻辑没设计好。连接但静音状态下，蓝牙射频接收机仍然工作，电流会比纯待机高很多，这类功耗的差异在产品宣传上可能只有毫安级，但在小容量电池音箱上会被放大。

射频合规方面要注意，蓝牙产品在多数国家和地区属于无线电发射设备，需要在当地法律允许的频段和功率范围内工作。量产前要重点确认蓝牙整机的发射功率、带外杂散、接收灵敏度是否符合设计目标，并在正式销售前完成所在市场的合规测试或取得相应认证。不是只要把样品调到能连接，就能直接大规模上市。

音频编码器的实现也存在潜在的授权要求。A2DP 支持 SBC 编码是基础要求，许多蓝牙音频芯片也支持 AAC、aptX、LDAC 等专有编解码或可选编码。产品量产时使用具有专利或商业授权的编码方案，需要确认已获得相应授权或者压缩编码器是否由上游芯片厂商合法提供。方案评估阶段就应把这些法律边界纳入选型判断，而不是等产品定型后再去补授权，否则后期改硬件代价极大。

隐私和安全也是蓝牙产品设计的重要维度。蓝牙配对绑定信息、设备名称、上报电量等数据保存在 Flash 中，如果产品支持 App 控制、OTA 升级，则需要留意配对流程是否会被绕过、固件升级包是否被篡改、是否上传了不该上传的用户数据。建议所有用户相关数据本地处理，OTA 升级包加入签名校验，云平台通信链路加密。同时做好产品说明书中的提示，让用户了解蓝牙配对权限和隐私保护方式。

10. 最佳实践：从“能响”到“能稳定响”的工程习惯

结合多个项目推进阶段，我发现一个常见规律：越到后期，单个硬件问题的占比越小，“版本管理 + 日志 + 测试基线”缺失带来的问题占比反而越高。一套蓝牙音箱项目如果做得多，最好尽快建立起工程化的工作习惯。

第一，搭建一套最小可复现测试环境。将测试手机、测试电脑、音频设备、距离位置固定下来，把测试步骤固化成文档。蓝牙问题的出现往往依赖现场环境，没有固定基线就无法验证修改是否有效。测试环境中的手机系统版本要保持稳定，不要今天用 iOS 15、明天用 Android 15，否则问题归因容易混乱。

第二，固件和参数版本管理要严格。每次烧录到板子里的固件，都要记录提交号、编译时间和音频参数区内容。推荐把编译时间戳打印到串口日志里，当两个团队分别测试不同版本时，可以立刻确认自己拿到的是不是最新固件。

第三，日志设计要分层。应用层、协议栈层、音频 DSP 层尽量都能导出关键信息。量产阶段不一定每个人都会抓 HCI，但至少要通过日志确认：当前是否进入配对模式、A2DP 是否连接、音量事件是否触发、电池是否低电。串口日志要在软件发布前统一屏蔽高频冗余输出，否则会影响蓝牙实时性。

第四，批量任务和压力测试一定要提前搭建。如果计划做几十台样机的中试，在开始前就要准备老化支架。可以用一台电脑同时控制多个音箱进行循环播放、断连重连测试。如果希望自动化，可以使用 Python 脚本控制蓝牙开放接口，串口控制继电器为设备做断电上电循环。每一次测试生成 CSV 日志，统计断连率、回连失败数和播放卡顿次数。

下面给出一段自动老化测试的思路示意，用于设备循环播放和重连场景，不代表任何具体产品命令。

# 示意：循环脚本逻辑 # 1. 开启被测音箱 # 2. 通过主机蓝牙连接 # 3. 播放指定音频 30 分钟 # 4. 断开蓝牙并关机 1 分钟 # 5. 重新开机，判断是否自动回连 # 6. 记录日志并循环

第五，小批量试产阶段建立音频主观听感评分。客观设备测试和主观听感要结合，客观指标合格并不代表用户听感满意。可以组织固定 3 到 5 人，按低音弹性、人声清晰度、底噪、最大音量失真几个维度打分。主观评分不需要特别复杂，但要有固定曲目和播放声压。

现阶段把问题集缩小到具体现象，测试环境保持最简，解决问题后再逐项开放新功能。蓝牙音箱从能播放到音质稳定、从单机到 TWS 对箱、从手动按键到 App 控制，扩展方向很多。TWS 左右耳/双音箱同步涉及更复杂的时间同步和主从切换逻辑，App 控制要稳定使用 BLE 链路，EQ 调音要建立声学实验室标定方法。这些内容可以作为后续项目推进的方向，建议读者先把本机联调和量产老化测试跑通，再逐步扩展。