「找到对方」比想象中难
没有服务器的产品有一个必须自己解决的问题：两台设备怎么知道对方现在在哪。
有云端的方案不需要操心这件事——两边都去连同一个服务器，服务器负责牵线。代价是你的连接、有时还有你的数据，都要经过别人的机器。
本地直连没有这个中间人，所以手机必须自己在局域网里把 Mac 找出来。而局域网地址是会变的：路由器重启后重新分配、换一个 Wi‑Fi、Mac 从有线切到无线、公司网络的租约到期。每变一次，二维码里记的那个地址就过期一次。
如果处理不好，用户的体验就是「每换一次网络就要重新扫码」。下面三条路径就是为了不让这件事发生。
路径一：Mac 在断开之前先把新地址告诉手机
最优雅的一条，因为它发生在问题出现之前。
Mac 端一直在监听自己的网络变化。一旦发现自身地址变了，它会立刻朝当前连接推一帧消息，把新地址告诉手机。关键在于时机：这条连接此时通常正随着旧路由一起死去，但推送发生在它彻底断掉之前——于是手机在连接断开的那一瞬间，就已经记下了新网络上的可用地址。
这就是「自己找回来」和「等人举着二维码」之间的差别。等手机意识到断线时，它手里已经有了答案。
这条路径是尽力而为的：如果地址变化太突然，消息没能发出去，那就退回到下面两条路。
路径二：局域网服务发现
如果手上的地址都拨不通，手机会用标准的局域网服务发现去找——Mac 在网络里广播自己的存在和实际监听的端口，手机据此重新定位。
有两个工程细节值得说，因为它们直接决定了这条路好不好使：
- 广播的是实际绑定的端口，不是约定的端口。Mac 启动时会按一个候选序列去绑定端口，首选的那个被占用就顺延。所以广播和二维码里给的都是真实绑定的那个端口——手机永远不需要猜端口。
- 识别靠证书，不靠名字。局域网里可能有第二台 Mac，名字也可能被改过。真正确认身份的是首次配对时记录的证书，在握手时裁决，名字只是显示用的。
这条路径的失效场景很具体：服务发现依赖组播，而组播会被 AP 隔离、访客网络和某些路由器的过滤策略拦掉。跨子网也过不去。所以还需要第三条。
路径三：在自己的网段里找一遍
前两条都没结果时，手机会在当前所在的网段里直接找：并发地去试探每个地址上那个端口有没有东西应答，命中几个就停下来，再用证书确认哪个才是要找的那台 Mac。
这条路是有意做得克制的，因为它比前两条昂贵：
- 只扫小网段。家庭和办公室常见的网段规模很快能扫完；再大的网段要花掉大量射频时间，为了一个不确定的结果去耗电不划算。
- 只在应用打开时扫。锁屏放在兜里的时候不扫——那是纯粹的电量消耗。
- 只试记录中的那个端口。把所有候选端口都试一遍会让耗时成倍增长，而 Mac 换端口的情况由路径二的广播来兜底。
这些取舍的共同逻辑是：宁可少找回一次，也不要让一个装在口袋里的应用整天空转。
三条路都走不通的情况
诚实地说，有些情况是找不回来的，而且找不回来是对的：
- 两台设备不在同一个局域网。人在外面、电脑在家，没有云端中转就没有办法。这是产品边界。
- 跨子网。服务发现过不了子网，网段扫描也只扫自己所在的那个。
- 客户端隔离的网络。设备之间被禁止直接通信，三条路径同时失效。
这些时候应用会尝试几次然后安静下来，不再耗电，而不是无限重试。回到同一网络后，网络变化会触发新一轮尝试；点一下桌面卡片可以立刻连上。重试的具体节奏见断线重连是怎么工作的。
这些机制换来了什么
对用户来说，这三条路径最终只体现为一件事：配对一次，之后不用再管。
- 回家连上家里的 Wi‑Fi——自动连上，不用扫码。
- 路由器重启、Mac 地址变了——自动找回。
- Mac 从睡眠中醒来——自动接回。
- 换到公司的网络，Mac 也在那儿——自动连上。
需要重新扫码的情况只剩下几种真正意义上的重来：换了 Mac、重装了应用、主动忘记了设备、或者重置了配对码。日常使用中不该遇到。