推荐的默认方式
如果该设备可能对更广泛的 Elata SDK 用户有用，请将其放在上游的@elata-biosciences/eeg-web-ble 中。
这样可以集中管理传输行为，避免在多个应用中出现并行的适配器。
按目标选择
路径 1：放在上游的 eeg-web-ble 中
在以下情况选择此路径：
- 设备可以在浏览器中通过 Web Bluetooth 工作
- 该集成可能被多个应用复用
- 你希望传输行为只有一份共享实现
- 在 BLE 包下添加设备模块
- 复用
BleTransport - 添加模拟测试
- 更新使用者文档和设备说明
这是公开、长期集成的最佳路径，能让它成为 SDK 的一等公民。
路径 2：独立包
当设备需要的不仅仅是干净的浏览器 BLE 流程时，选择此路径。 典型原因：
该包仍应暴露
HeadbandTransport（或其轻量封装），以便应用代码与 Elata 技术栈的其他部分保持一致。
路径 3：应用本地适配器
当速度比复用更重要时，选择此路径。 适用于：- 私有的客户部署
- 快速的概念验证
- 在公开包出现之前的评估工作
决策顺序
1
判断集成是否应可复用
如果多个应用会受益，先假设走上游路径。
2
检查浏览器 BLE 的阻碍
如果 Web Bluetooth 无法工作，或需要原生桥接，请改用独立包。
3
确定长期支持由谁负责
共享支持通常属于上游。由厂商负责的发布线通常更适合独立包。
4
保持应用协议稳定
无论代码放在哪里，面向应用的协议都应是
HeadbandTransport 和 HeadbandFrameV1。应避免的路径
不要仅仅因为第一个小时最容易就选择应用本地适配器。 如果集成之后需要公开，这通常会带来额外工作。 也不要把较重的、基于桥接的或需要许可证的集成塞进共享的 BLE 包。保持公开包精简。相关文档
下一步
传输协议
查看你所选路径仍需满足的共享接口。
协议要求
在实现前收集所需的协议细节。