推送里的号码匹配：先对数字再批准的原因
如果你批准推送时多了一步「从列表里选出登录页显示的数字」，那是组织开启了号码匹配。这个看似多余的步骤，堵的是推送验证的一个真实漏洞。
它防的是什么
早期的推送验证有个弱点：攻击者反复触发登录请求，受害者的手机就会被一连串推送轰炸——「轰炸疲劳」之下不少人手滑点了批准。号码匹配把「闭眼点同意」变成了「必须看着登录页上的数字来选」：手机不在攻击者面前、看不到那个数字，瞎选是过不了的。
开启后的登录流程
- 登录页验证步骤会显示一个两三位数字（同时出现推送请求）；
- 手机收到推送，点开后同样进入数字选择界面；
- 在手机上选出与登录页一致的数字；
- 数字对上，批准才生效。
官方文档同时说明：风险评分引擎会与号码匹配联动，高风险登录场景会加强挑战。
用户侧的适应点
- 数字看不清别乱选：登录页被遮挡时先把窗口带到前台，看清数字再选；
- 没有数字的推送要警惕：组织已开启号码匹配时，一条不要求选数字的「批准」请求本身就可疑——正常流程必须有数字环节；
- Apple Watch 批准同样适用：手表端批准同样要过号码匹配这一关，流程一致。
为什么有人没这一步
号码匹配是否启用由组织配置（且依赖登录组件的版本支持，官方要求较新版本的登录组件才能配套使用）。同事没有而你有时，多半是两边的策略或组件版本不同，不是应用故障。