第一次接阿里云验证码的开发者，常把两件事混在一起。一件是页面上的滑块或点选，用来挡住机器注册和刷接口。另一件是手机收到的短信验证码，用来确认手机号是不是本人。两者都在阿里云控制台里，但产品和配置入口不同。这篇文章先把两者分开，再讲接入步骤、三个案例，以及常见报错怎么查。
一、先分清两类验证码
人机验证（验证码服务）：在登录、注册、发短信、提交表单之前弹出滑块或文字点选，判断操作的是人还是程序。它管的是“谁在频繁请求”。
短信验证码（短信服务）：服务端生成随机数字，通过短信发给用户，用户填回来，服务端比对通过才算数。它管的是“这个手机号是不是本人”。
两者通常串着用：先过人机验证，再发短信。脚本没法批量刷短信，每条短信也只发给真人，费用才可控。
二、接入前的准备
- 阿里云账号先完成实名认证。
- 确定业务端是 Web 页面、H5、小程序还是 App。端不同，接入组件和 SDK 也不同，动手前要先定下来。
- 要发短信的话，提前准备短信签名和模板。两者都需要审核，通常要花一些时间，建议上线前一周提交。
- 服务端密钥只放在环境变量里，不写进前端代码，也不要提交到代码仓库。
三、接入步骤
- 新建验证场景。在控制台的验证码服务里，为每个业务单独建场景，比如登录、注册、找回密码各一个。之后要调高某个场景的拦截强度，就不会影响其他页面。
- 拿到接入参数。按端选择对应的 SDK 或前端组件，记下场景标识等配置。
- 前端嵌入验证组件。用户点到敏感操作时再加载组件，验证通过后会得到一个一次性令牌。令牌只能用一次，别在前端长期存着。
- 服务端校验令牌。后端把令牌和场景标识发给阿里云校验接口，返回通过后才继续发短信或写库。前端传上来的“已通过”标记不可信，要以服务端的校验结果为准。
- 接入短信验证码。服务端生成六位随机数，设 5 分钟有效期（这是常见设置，可按业务调整），存进缓存并和手机号绑定。用户提交后比对，成功即删除，防止重复使用。
四、三个案例
案例一：注册接口被脚本刷
某内容社区上线第二周，注册量猛涨，次日留存却几乎为零。日志显示，同一个出口 IP 一分钟内提交了上百次注册。团队在注册表单前加了人机验证，并且只有服务端校验令牌通过后才写库。接入后，异常注册请求降到原来的十分之一以下。（示例数据，发布前请替换为真实统计。）
案例二：短信费用超出预算
某电商小程序的找回密码功能没有人机验证。攻击者不断换手机号触发短信，当月账单明显超出预算。处理分两步：发短信前加人机验证；同一手机号和同一 IP 设每日发送上限。之后短信调用量回到正常水平。
案例三：用户收不到短信
一款教育类 App 上线后，部分用户反映收不到验证码。排查顺序是：先看短信模板有没有审核通过，再查发送记录的状态码，最后检查手机号是否带了国家区号。最终发现，新模板的参数名和代码里的不一样。改成完全一致后问题消失。模板变量名要和代码逐字相同，大小写也算。
五、常见报错怎么查
- 令牌校验失败：多数是令牌已经用过一次，或者超过了有效期。看看前端会不会重复提交，也看看后端是不是在校验之前就把令牌消费掉了。
- 短信发送失败：先查签名和模板的审核状态，再看账户余额和发送频率限制。
- 用户频繁被拦截：先别急着降低验证强度。翻一下拦截日志，确认是不是正常用户被误判，再决定调哪里。
六、上线前要做的几件事
验证场景和业务接口一一对应，别让所有接口共用一个场景。短信要设发送次数上限，并盯着每日用量，出现异常时及时报警。
在测试环境里用真实手机号把流程完整走一遍，成功、失败、过期、重复提交四种情况都要测到。
密钥要定期轮换。有人离职，他的访问权限要及时回收。
