使用GenerateChangePhoneNumberTokenAsync实现邮箱验证是否合规可行？

这套流程在当前版本环境下可以正常运行，不属于违反通用合规要求的实现，但属于对ASP.NET Core Identity内置方法的非预期用法，不建议长期使用，存在以下几类潜在问题：

• **方法迭代兼容风险
  你当前使用的GenerateChangePhoneNumberTokenAsync、VerifyChangePhoneNumberTokenAsync两个方法本身是为手机号变更场景设计的，虽然你传入邮箱参数可以完成生成、验证逻辑，但如果后续Identity框架版本迭代时，有可能调整该方法的校验逻辑：比如新增传入参数的格式校验，强制要求参数为手机号格式、或者新增手机号相关的绑定校验逻辑，你的代码在升级框架版本后会直接失效，稳定性完全依赖框架对该方法的向下兼容，后期维护成本很高。
• **业务逻辑冲突风险
  如果你后续需要开发手机号绑定、变更相关功能时，同一系列方法混用邮箱、手机号参数传错的概率会大幅提升，这类逻辑问题排查难度很高，容易出现意料之外的业务bug。
• **安全防护缺失风险
  6位纯数字验证码本身枚举成本极低，全量组合仅100万种，如果你没有给配套防护逻辑：
  • 验证码有效期限制（建议10-15分钟）
  • 验证接口请求频率限制（单用户每分钟最多3-5次请求）
  • 验证失败次数上限（失败5次直接作废当前验证码，要求重新发送）
    很容易被攻击者暴力破解，邮箱验证逻辑形同虚设。

如果要适配无视图、不需要点击链接的验证方式，建议优先用原生适配的方案：可以自定义邮箱验证码令牌提供器，针对邮箱验证场景生成6位数字验证码，或者直接自行实现验证码的生成、存储、过期校验逻辑，稳定性远高于借用手机号相关方法的实现。

内容的提问来源于stack exchange，提问作者Varin