加载失败
Bluetooth Core Specification 6.2 发布，宣称改进响应性、安全性、USB 通信与测试能力，但评论主要围绕长期存在的“开启麦克风时音质骤降”问题展开。讨论把问题归因于 HFP（Hands‑Free Profile）与老旧编解码的带宽限制，并把 LE Audio（基于 BLE 的音频扩展，采用 LC3）与 GMAP（Gaming Audio Profile）视为规范层面的解决方案，但现实中硬件、驱动与平台（Windows、Linux 的 BlueZ、Android）支持严重碎片化。配对 UX 也被频繁提及：规范中有 OOB（out‑of‑band）配对（USB/NFC）等方法，但消费设备大多不实现或采用厂商专有方案，导致跨平台体验不一致。用户普遍采用外接 USB 麦克风、切换系统输入或专用 dongle 等权宜之计来缓解通话质量问题。
大量评论指出“打开耳机麦克风时音质变烂”并非幻觉：设备在 A2DP（高质量单向立体声）与 HFP（Hands‑Free Profile，双向通话）之间切换时会降用低比特率编码（如 mSBC 或更差），导致双向通话和听感都受损。实际可行的短期对策包括在笔记本上把输入切换为内建或外接 USB 麦克风以避免耳机进入 HFP，或直接购买独立 USB 话筒来提升通话端声音。多个评论把 AirPods 视为例外，认为其依赖 Apple 的专有编解码和额外 DSP 处理，而不是通用蓝牙标准本身的优势。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
评论普遍把 LE Audio（基于 BLE 的音频扩展，采用 LC3 codec 与 isochronous 通道）和 GMAP（Gaming Audio Profile，目标支持 48kHz 立体声 + 麦克风）当作规范端的正确方向，但现实中软硬件链路还未成熟。有人列举 WH‑1000XM6、WF‑1000XM5、JBL 等设备在不同平台上尝试 LE/GMAP 的失败案例，Windows、Linux、Android 在 isochronous 与应用识别上有兼容性问题。还有用户抱怨厂商因固件问题撤回 LE 特性或因认证成本不愿为已出货设备重做认证，导致规范虽有进步但用户端体验仍罕见。
很多评论聚焦在操作系统与芯片驱动层面的现实障碍：Windows 需要 BLE v5.2 和 isochronous 音频支持，Linux 的 BlueZ 与内核对新版特性支持滞后，部分 Intel/Mediatek 芯片在驱动或专有 DSP 上存在兼容性问题或闭源依赖。具体例子包括 Linux 上几乎找不到支持 isochronous 音频的 USB dongle、某些厂商 dongle 自带专有堆栈并需要闭源配置工具，以及关于 Intel 驱动与特定 CPU 平台不兼容的报告。评论认为即便规范定义了功能，硬件认证成本、驱动质量和厂商商业决策也会显著延缓普及。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
关于配对，评论分为两派：一方指出规范中存在 OOB（out‑of‑band）配对机制，可通过 USB 或 NFC 进行密钥交换（PS3/PS4、Switch Pro、带 NFC 标签的音箱都曾用到），理论上更安全且用户体验更好。另一方指出消费设备很少实现完整的 OOB，因为这要求周边设备具备 USB 数据接口或 NFC 标签，会增加成本与复杂度；厂商倾向用 Quick/Fast Pair 或按键配对，且实现互不兼容。还提及 Apple、Microsoft、Sony 等各自的专有配对实现，使跨平台配对体验参差不齐。
多条评论提到蓝牙规范庞大（千页级别）且历史累积了大量遗留特性，厂商出于向后兼容和维护成本考虑不愿彻底抛弃旧模式。还有观点认为 Qualcomm 的专利与营收动机，以及 Apple 对专有扩展的偏好，会在 SIG 和生态中阻碍对开放、现代化音频方案的一致采纳。前行业从业者补充了现实工程成本：针对大量设备逐一修补驱动和固件维护工作量巨大，这也让更新节奏非常缓慢。
面对标准与硬件滞后，用户大量分享权宜之计：把通话输入切换为笔记本内建或外接 USB 话筒（USB podcast mic、lapel mic、ModMic、Tonor 等），在 macOS 用 aggregate device 防止耳机劫持麦克风，或购买自带堆栈的 USB‑C dongle（例：某些 Sennheiser 设备）来规避操作系统对新特性的支持不足。多位用户证实这类方案在通话清晰度和延迟上带来显著改善，但评论也普遍认同这只是暂时的工程解决，无法替代标准与广泛硬件支持。
少数评论为蓝牙辩护，强调在现实场景中它的鲁棒性与覆盖范围仍然出色：有人报告在多层建筑甚至忘记手机在地下室时耳塞不中断，另有用户惊讶于 PS5 控制器在背包中仍能短距离连通。与此同时也有理性的讨论指出 2.4GHz 频谱的物理限制（穿透、拥挤、功耗）使得提升带宽与低延迟存在权衡，很多限制来源于实现与功耗策略而非协议理论上能做不到。总体讨论把问题既归因于实现/驱动生态，也归因于频谱与功耗的工程折中。
LE Audio: 基于 Bluetooth Low Energy 的音频扩展规范，采用 LC3 codec、支持 isochronous channels、多流和更高效的双向音频，目标解决传统 HFP/A2DP 在通话与立体声并存时的限制，但需要硬件与驱动端完整支持。
HFP (Hands‑Free Profile): 传统用于免提与双向通话的蓝牙配置文件，因带宽与编码限制（常用 mSBC 或更低）在开启麦克风时导致音质和立体声降级。
GMAP (Gaming Audio Profile): LE Audio 生态下提出的 Gaming Audio Profile，旨在支持低时延的 48kHz 立体声同时带麦克风的双向音频，用于游戏等场景，但消费级设备中完整实现罕见。
mSBC: 一种在 HFP 中常用的语音编解码（比 G.711 好但仍低比特率），能在有限带宽下提供双向语音，但音质与鲁棒性远逊于现代高保真编解码。
A2DP: Advanced Audio Distribution Profile，用于单向高质量立体声（音乐）流。A2DP 与 HFP 在用途与编码上不同，切换会影响通话或音乐的音质与立体声表现。
LC3: Low Complexity Communication Codec，LE Audio 推荐的现代编解码器，设计目标是在更低比特率下提供更佳音质，是 LE Audio 改善通话与音乐体验的核心之一。
OOB pairing (Out‑of‑band pairing): 规范允许通过 USB、NFC 等带外信道交换密钥以避免配对时的中间人攻击并简化配对流程，但要求外设增加 USB/NFC 数据接口，消费实现较少。