蓝牙场景下busctl注册的对象名是否可与Address属性值不一致

我正在开发一款符合POSIX标准的蓝牙相关Shell脚本，计划对外公开发布，目前处于代码优化阶段，后续会公开代码供社区评审。 #

我当前获取和主机（即运行脚本的设备）配对的所有蓝牙设备的实现代码如下：

busctl tree org.bluez > $tempfile
while read mac; do
    t=$(echo "${mac##*/dev_}"| grep -v "└─/org")
    a=${t%%/*}
    # 丢弃子地址导致的重复项
    if [ -z "$a" ] || [ "$a" != "$t" ]; then
        continue;
    fi
    # 此处省略其他运行逻辑
done < $tempfile

拿到循环内的对象名后，我通过以下方式查询它的Address属性以及其他未展开说明的属性：

c=$(busctl get-property $SERVICE $OBJ_TEMPLATE"$a" $INTERFACE Address)
c=${c##s }
# 返回结果类似 " 00:00:00:dd:33:22"

我观察到绝大多数场景下，busctl tree返回的对象名格式化后和Address属性的返回值是对应的，上面的查询步骤看起来很冗余。但我担心busctl侧或者设备侧异常会导致二者不匹配，比如busctl tree返回的某行内容为├─/org/bluez/hci0/dev_00_00_00_00_B5_C8，但get-property查询返回的是s 22:33:21:25:AA:B4，所以想确认：是否应该把对象名视作别名处理，而不是遵守固定的通用命名约定？ #

• 不要省略get-property查询Address的步骤，也绝对不要依赖D-Bus对象路径中的dev_xxx段提取MAC地址。BlueZ的官方D-Bus规范中，对象路径的命名规则属于实现细节，没有对外承诺长期稳定。当前版本确实是将MAC地址的冒号替换为下划线后拼接在dev_后生成路径，但未来版本完全可能修改命名规则，特殊场景下（比如虚拟蓝牙设备、多适配器重名处理、桥接蓝牙设备）也会出现路径字段和实际Address属性不一致的情况，你担心的不匹配问题是真实存在的。
• 你当前的实现还有更稳定的优化空间，不需要解析busctl tree的输出：busctl tree的树形标记输出格式会随systemd版本、系统locale变化，你现在的grep过滤规则很容易失效。更可靠的方式是直接调用busctl call org.bluez /org/bluez org.freedesktop.DBus.ObjectManager GetManagedObjects拉取所有托管对象，直接过滤类型为org.bluez.Device1的对象即可，不需要自行裁剪路径、去重。
• 如果想要减少查询次数，还可以直接从GetManagedObjects的返回结果中批量提取Address等所有需要的属性，不需要逐次调用get-property，执行效率和稳定性都比你当前的方案更高。

内容的提问来源于stack exchange，提问作者Imeguras