O3.15.2Recovery versus protection设计
找回设备与保护数据两个目标在丢失场景下可能冲突
别名: 找回与擦除冲突 · lost mode · anti-theft tradeoff
概念解释
设备丢失后有两条目标线：找回（设备保持可达、可定位、能被联系）与保护数据（锁死、隐藏、必要时擦除）。每个保护动作都在削弱找回的概率——擦除后定位停摆、锁定后拾获者失去联系渠道。两个目标在同一时间线上互相挤压，处置流程必须显式排序，不能假装兼容。
机制
冲突的根源是定位与锁定共用同一条设备侧能力链：定位需要设备联网并运行定位服务，通常意味着设备处于「可用」状态；保护动作恰好逐项关掉这些能力，且擦除指令本身要等设备联网才执行——两个延迟叠加，先擦除几乎必然终结找回。时间也对冲：找回的成功率集中在丢失后头几个小时，而恐慌驱动的第一反应往往是立即上最强保护。所以分级处置是结构性必需而非产品偏好：先「丢失模式」（锁屏加失主联系方式，定位持续），再「降权」（登出会话、冻结支付），最后才是「擦除」这个不可逆终点。
边界
分级的前提是「找回有价值」：落入陌生人且载有高敏数据（企业设备、医疗记录）时，泄露成本压倒找回价值，直接擦除正确。丢失模式把「显示联系方式」与「锁定」解耦的程度由平台决定，跨平台不能假设一致；分级触发条件（多久无定位、有无解锁尝试）没有通用数值，按设备价值与数据敏感度定，且要接受误判——保守分级多暴露一阵数据，激进分级错杀找回机会，两个错误方向都要在流程里被允许。
怎么落地
- 处置流程固定三级并各配触发条件：丢失模式（默认第一步）→ 降权（如 24 小时无定位）→ 擦除（确认放弃找回或确认高敏）；条件写进产品逻辑而非客服话术。
- 丢失模式里的联系方式用备用号码或邮箱，不暴露主账号；定位持续上报但仅失主可见。
- 用户界面把三级的后果写清：「擦除后定位将停止」必须是擦除确认框里的一句话。
- 验证：把三级流程做成桌面演练脚本（48 小时无定位、异常解锁尝试等给定场景），核对每级动作与触发条件是否自洽，演练记录即流程回归用例。