“扫描附近设备”听起来像路由器管理页面：点一下，网页就把家里所有手机和电脑列出来。现代浏览器不会给普通网站这种权限。网页既不能任意遍历局域网 IP，也不能悄悄探测每个端口。一个可用的设备发现功能，实际是在隐私限制内，让同样打开了服务的设备短暂地互相可见。
这反而是好事。设备发现的目标不是画一张越全越好的网络地图，而是减少连接码输入，同时避免咖啡店、公司或共享网络中的陌生人获得过多信息。
网页里的“发现”可能指三件事
同公网出口发现由服务端根据短期在线登记，把共享同一出口地址的 uCopy 设备放进候选列表。它适合家庭或小办公室，但同出口不一定等于同一个可信局域网：企业代理、校园网和运营商 NAT 可能把许多陌生人放在同一出口。
WebRTC 候选发现发生在双方已经通过信令认识之后。浏览器收集可用网络候选并尝试直连，它解决“怎么走”，不负责先列出“附近有谁”。原生局域网发现通常依赖 mDNS、系统附近共享或安装的客户端，普通网页能做的范围更窄。
一个完整的发现闭环
- 上线：设备明确开启发现，向服务登记匿名设备 ID、显示名和短期在线状态。
- 可见：同条件设备获得候选摘要，信息只够辨认，不暴露完整 IP、浏览器指纹或长期活动记录。
- 请求：A 选择 B，发送一次有过期时间的连接请求；列表里的出现不等于连接成功。
- 同意：B 查看 A 的名称与已有信任状态，首次连接主动接受或拒绝。
- 验证：WebRTC 建立后，双方在通道内核对设备密钥，防止信令中的名称被冒用。
- 连接：进入工作区，发现请求结束，不再反复弹窗。
- 离线：心跳过期后及时从列表移除；旧记录不能表现为仍可连接。
- 阻止：用户可关闭发现、停止重连或拉黑设备，这些意图在刷新后仍然有效。
很多“扫描不好用”并不是第一步没返回列表，而是后半段断了：设备已下线却一直显示、拒绝后立刻又收到请求、已经信任的设备刷新时再次要求首次同意。测试必须从出现一直走到退出和再次上线。
为什么两台设备互相看不到
先确认两边都打开了发现且页面仍在线。若一台使用 Wi-Fi，另一台使用蜂窝网络，它们通常不共享出口。VPN、企业代理和隐私中继会改变出口；双路由、访客 Wi-Fi也可能把看似同一地点的设备隔开。
服务端状态也有时间窗口。设备刚上线需要一次登记传播，离线则要等短 TTL 过期。刷新按钮不应无限创建新扫描任务，而应取消旧请求、展示最后更新时间，并在超时后给出连接码作为可靠替代。
看得到但连不上，问题在下一层
发现成功只证明信令服务把候选介绍给了双方。连接还会经历接收方同意、ICE 候选交换、直连或 TURN、通道身份验证。请求超时应明确显示在哪个阶段，而不是从列表里消失后让用户猜。
若 B 拒绝，A 应停止该请求并进入冷却；若 B 没看到通知，可以重新唤醒一次，但不能高频轰炸。双方同时点击连接时，协议应合并为一个握手，由确定性角色规则决定谁发送 offer，避免两条连接互相覆盖。
发现功能应少透露什么
候选卡片通常只需要用户设置的设备名称、粗略设备类型、是否曾经信任和最近在线状态。局域网 IP、完整公网 IP、User-Agent、网卡列表、长期在线轨迹都不该暴露给其他候选设备。设备名称也应有默认脱敏，避免自动带出真实姓名或电脑资产编号。
分析事件可以记录发现是否有结果、耗时区间、请求结果和失败阶段，但不记录候选列表、设备 ID 原值或网络地址。安全风控需要的散列标识和短期日志，应与产品分析分开保存并限制访问。
把“扫描成功”测成闭环
至少覆盖：列表为空；一台设备上线后出现；关闭发现后消失；A 请求、B 接受；A 请求、B 拒绝；请求超时；双方同时请求；连接后 A 刷新；连接后双方同时刷新；B 拉黑 A；VPN 开关导致出口变化；访客网络下发现但只能中继；离线记录过期。
每个场景同时检查两边界面、通知数量、信令请求数和最终连接数。只断言“API 返回一个设备”远远不够，重复通知、幽灵在线和双连接恰恰都发生在 API 成功之后。
在 uCopy 中使用发现
在两台设备打开 连接页面并启用发现。看到候选后核对名称，再向对方发起请求。首次连接由对方确认；已有信任的设备恢复时会验证身份并尽量安静重连。若列表为空或网络条件不同，直接使用临时连接码，不必反复刷新。
理想的发现功能不是让列表永远热闹，而是在需要时快速找到正确设备，连接后退到背景，用户明确拒绝或停止时马上安静下来。