摘要

  • 手机删除一项网络配置，与接入服务不再识别它，是两件事。随机地址的生成方式，不能代替对保留期限和复用范围的说明。
  • RFC 9724 区分按设备、启动、网络、周期及会话等方式选择地址；当前 Apple 与 Android 文档也显示，私有地址可以持久，也可以在特定条件下更换。
  • 需要先明确业务究竟要保留哪一段连续性，再判断标识是否合适。为了兼容旧系统而恢复跨场景的长期识别，不只是一次技术修复。

“忘记”是一个让人容易产生期待的词。用户删掉一项 Wi-Fi 配置，可能以为下一次接入就是一次全新的相遇；运维人员重新看见熟悉的地址，也可能据此判断隐私功能没有生效。双方都可能把一个界面动作，理解成了它并未完整承诺的结果。

Android 的官方框架说明恰好提醒人们注意这个边界：持久随机地址依据网络配置参数生成，忘记并重新添加同一网络，并不会因此重新生成地址。这不是本次测试发现的异常，而是文档明确描述的行为。判断是否符合预期，首先要知道自己期待的是“删除连接配置”，还是“结束对端能够识别的连续性”。

两者不能靠一个词合并。手机保留什么、网络看见什么、服务系统记住什么，可能属于不同的状态。用户操作其中一项，并不等于另外两项同步清空。

先问地址什么时候结束，再问它是不是随机的

随机描述一次取值过程，持久描述这个值之后怎样使用。一个设备可以随机选出地址，再长期沿用；也可以为每个网络保留不同地址，在回到同一网络时恢复使用。观察到地址没有变化，不能单独证明生成机制失效。

2025 年 3 月发布的 RFC 9724 把这些差别分开命名。它是信息类文档，并非提出新协议的标准轨规范。其分类包含出厂分配的传统形式，以及按设备、启动、网络、周期和会话生成的地址；实现还可以组合不同策略。按设备生成的随机值甚至可以保存到设备寿命结束。RFC 9724

因此，一份采购要求若只写“支持随机 MAC 地址”，其实留下了重要空白。供应方证明没有使用硬件地址，并不等于证明旧观察与新观察很快就无法关联。反过来，业务希望短暂断线后仍能恢复服务，也不必然要求设备在所有网络上交出同一个硬件标识。

作用范围同样需要说清楚。一个网络配置、一栋建筑、一个运营主体和一个用户账户，并不是相同的分组方式。把“每个网络不同”直接解释为“每次换地点都不同”，中间缺少关于网络识别方式的证据。地址策略针对的边界，未必与读者心中的地点边界重合。

这正是随机与更换必须分别验收的原因。前者回答取值从何而来，后者回答什么时候重新取值；还有第三问：什么变化才被系统视为进入另一个上下文？

同样写着“私有”，行为也可以不同

Apple 的当前说明，从 iOS 18 及其列明的其他系统对应版本起，区分关闭、固定和轮换三种选择。固定模式使用私有地址但不定期轮换；新加入采用 WPA2 或更强安全机制的网络时，文档给出的默认选择是固定。对于安全机制较弱或没有安全机制的新网络，默认选择是轮换，私有地址每两周更换。文档还单独规定重置与忘记网络的行为，所以“固定”不能被扩展为任何操作下都永远不变。Apple 私有 Wi-Fi 地址说明

这里不能再悄悄增加一个推论：采用 WPA2 的网络，就值得把所有活动长期交给其经营者识别。链路安全条件可以影响平台默认值，却不能证明对方如何保存、共享或使用记录。默认选择并不替代对机构数据实践的判断。

Android 的安排也不能用 Apple 的时间表解释。AOSP 文档把持久随机化列为默认类型，取值依赖网络配置参数，其中包括 SSID、安全类型，或 Passpoint 场景下的 FQDN。Android 12 起，特定应用请求，或者满足条件且启用了相应配置的开放网络，可以采用非持久随机化；该开放网络配置并不是默认开启。

即便采用非持久策略，也不能概括为“每次连接一定换号”。文档列出的条件包括：DHCP 租期已届满且断开超过四小时，或者当前随机值生成已超过二十四小时。重新生成发生在新连接开始时；系统不会仅为换地址而主动断开正在使用的 Wi-Fi。不满足条件时，旧值仍可能复用。AOSP 的 MAC 随机化行为说明

所以，地址年龄达到某个门槛，与当前业务立即中断，不是同一个事件。把“超过二十四小时”写成“每天固定掉线一次”，会在尚未观测设备之前就制造错误的故障模型。把开放网络统称为必然轮换，同样忽略了明确的配置条件。

以上描述来自平台文档，不是对全部厂商设备的现场结论。本篇没有运行设备实验。RFC 9724 自带的操作系统测试表还明确标注，其测试发生在 2021 年 9 月；这份历史记录不能成为 2026 年设备群现状的替代品。

业务究竟需要记住什么？

为了让用户不用反复登记，一项服务可能需要跨越短暂断线保留状态；为了恢复已经选好的偏好，也可能需要在明确期限内识别再次接入。这些都是可以讨论的需求，不必先被判定为不合理。

但需求应当从服务开始描述，而不是从现有数据库键开始描述。“我们的旧系统一直按 MAC 存记录”，说明的是已存在的依赖，并没有说明依赖需要覆盖多大范围、持续多长时间。若把已有实现当作最终理由，任何隐私改进都可能被重新定义成兼容性故障。

更有用的提问是：失去连续性以后，哪一个具体功能不能工作？它需要识别同一网络内的再次访问，还是确实需要连接不同网络中的记录？所需期限能否与服务期限一致？如果缩短期限会增加支持成本，这个成本应单独估计，而不是藏在“请关闭私有地址”的建议里。

稳定的私有地址因此不是逻辑上的折中失败。它可能保留局部便利，同时不必沿用各处都相同的硬件值。至于它是否足够，必须由明确的服务目标与观测结果决定，不能从“稳定”或“随机”两个词直接得出好坏判断。

最值得警惕的，是为了使某个局部系统继续认人，而默认恢复更广泛的识别能力。局部便利的收益立即出现在支持工单里；跨场景关联的代价，往往并不由同一个团队承担。

地址变了，关联不一定断了

链路层只占整个通信过程的一部分。RFC 7844 解释了 DHCP 带来的关联问题：如果 MAC 地址改变，而 DHCP 标识等其他信息保持稳定，观察者仍可能把前后记录连接起来。匿名配置要求这些标识围绕隐私目标协调变化，但也不消除所有设备或无线信号指纹。RFC 7844 第 2 节

这不是说 Apple 或 Android 的一个开关就实现了该规范的全部要求；现有文档也不足以支持这样的结论。它提醒的是验收声明应保持边界：究竟减少了哪一种关联路径，哪些路径尚未检查？

同样，存在更复杂的关联手段，并不意味着减少最容易的识别方式没有价值。“不能阻止所有观察者”与“什么也没有改变”之间，有很大的距离。把隐私功能吹成彻底匿名，和因为它不是彻底匿名就要求关闭，都是把分层能力压成了一道选择题。

真正应交给管理者的，是一项可以解释的记忆安排：为指定服务保留必要的连续性，让不再必要的连续性有明确终点。先把这项安排说清楚，才知道下一次看见相同或不同的地址时，究竟应当庆祝、排查，还是只记录一个正常事件。