诊断修复 · 系统缓存
诊断通过了，但位置就是不变？
WLOC 已确认兼容网络响应完成 patch，但目标 App 仍显示旧位置或真实位置。patch 只能证明其中一层，不代表 iOS 或目标 App 一定采用该结果。请按顺序核对时间、新请求、App 缓存、权限、GPS 条件与 App 自身规则。
大白话解释
为什么会这样
iPhone 的定位结果可能综合 GPS、Wi‑Fi 与蜂窝网络定位、蓝牙、权限、近期系统状态，以及目标 App 自己的缓存或服务端逻辑。WLOC 诊断可以证明受支持网络链路上出现了新的兼容请求与 patch，但无法证明目标 App 最终使用了哪一种信号。请把请求时间、patch 时间、权限状态、App 刷新和实际结果分别记录。
第1步：先证明请求与 patch 都是新的
重新运行诊断，把最近请求和 patch 时间与重新打开目标 App 的时刻进行比较。如果时间没有更新，先修复兼容客户端、限定主机的 HTTPS 配置或请求链路；两项都更新后，再继续做 App 刷新和权限检查。重启只应作为授权测试设备仍有陈旧状态时的后续升级动作；Apple 没有公开 iOS 26 或更高版本必须为 WLOC 重启的专属规则。
- VPN 图标不是充分证据，要查看最近请求与 patch 时间
- 没有新请求：重新打开目标 App，并复核其定位权限
- 有新请求但没有 patch：回到配置与证书检查
- 已有新 patch 但结果陈旧：继续核对 App 刷新、权限和受控信号条件
第2步：强制退出目标 App
你正在测试的 App（地图、外卖、打车、交友 App 等）可能自己缓存了上一次的位置。从屏幕底部向上滑（或双击 Home 键）打开 App 切换器，把目标 App 向上滑出彻底关闭。再重新打开。这会强制 App 向系统请求新的位置，而不是使用自己的缓存。
- 从底部上滑 → 找到目标 App → 向上滑出关闭
- 不要只回到主屏幕——那样 App 还在后台运行
- 强制退出后重新打开，App 会请求新位置
第3步：刷新目标 App 的定位权限
在授权测试账号中，进入 设置 → App → [目标 App] → 位置，先记录当前权限。如果测试需要一次新的询问，可改为「下次询问或在我共享时」，重新打开 App，并只授予场景所需的权限。这可能触发新的定位请求，但不能保证 App 会清除所有缓存或优先采用已 patch 的网络结果。
- 改变前先记录原权限
- 重新打开 App 后观察 WLOC 请求时间是否更新
- 测试结束后恢复原权限
- 把新权限弹窗当作证据，不要当成必然清缓存的保证
第4步：比较一个可控的室内条件
确认存在新的请求与 patch 后，可以在稳定室内环境中重复授权测试并记录结果。GPS 和其他信号可能影响结果，但不存在能保证网络结果一定被采用的通用优先级规则。保持账号、权限、目标位置和 App 状态不变，让每次比较只回答一个问题。
- 保持相同目标、账号、权限和 App 版本
- 同时记录请求时间、patch 时间和目标 App 结果
- 不要仅凭状态栏箭头判断正在使用的具体传感器
- 如果结果不同，把条件作为证据记录，不要描述成万能修复
FAQ
为什么不同尝试的结果会变化？
请求可能不是新的，目标 App 可能复用自己的状态，权限条件可能改变，也可能有其他定位、账号或服务端信号参与。每次只改变一个条件，并把 WLOC 时间戳和实际结果放在一起比较。
状态栏箭头能证明 GPS 覆盖了 WLOC 吗？
不能。箭头只能说明某个 App 最近使用了定位服务，不能说明最终采用了哪些传感器，也不能证明目标结果为什么被选择。它只能作为诊断与 App 证据之外的背景信息。
应该连接 CarPlay 或外部定位来源做测试吗？
除非你明确获准验证的功能本身就是该连接，否则优先使用只有 iPhone 的可控条件。车载或外部定位会增加新的变量，应该单独记录与比较。
WLOC
用新鲜时间戳，把模糊的“不生效”变成明确下一步。
WLOC 验证的是其中一条兼容网络定位链路。分别对比请求、patch、权限、App 刷新、实际结果与恢复证据，才能说明发生了什么，而不是猜测一条通用 iOS 缓存规则。