S27-J03 · 验证码与风控：滑块设计与实现

适用读者：要挡脚本、又不想挡用户的人。
前置：S27-B04（微信生态，含验证码映射）。
覆盖旧文：405(341) = 341 点。
扩展点：E-S27-013（滑块难度与通过率）。
上一篇：S27-J02 · 缓存预热与分布式锁
下一篇：S27-J04 · AOP 与对象转换。

1. 一句话结论

滑块的难点不是"拼图对齐"，而是"区分人和脚本"：服务端要校验轨迹、时效、一次性，而不是只比对缺口位置。

层	校验什么
前端	缺口位置（易被绕过）
服务端	轨迹合理性 + 时间窗口 + 一次性 token
风控	频次、设备指纹、行为特征

2. 滑块的四道校验（E-S27-013）

校验	说明
位置容差	允许 ±N 像素（人不会精确）
轨迹特征	加速度/停顿/抖动（脚本常匀速直线）
时间窗口	太快=脚本，太慢=超时
一次性 token	通过后作废，防重放

判据："只校验位置，能挡住脚本吗？" 不能——位置是最好伪造的一维。

3. 难度设计：通过率的两难

难度	通过率	拦截率
太简单	高	低
太难	低	高（但误伤用户）

"怎么定难度"：用真实用户通过率做指标（目标 90–95%），而不是"看起来难"。

注意：风控要能"降级"——异常流量时提高难度，正常时降低。

4. 与业务链路的集成

环节	要点
发放	服务端生成 token（一次性）
校验	校验通过后立刻作废
失败	计数 + 升级（短信/二次验证）
日志	记录失败原因分布（调难度用）

5. 五个误区

误区	真相
"前端校验够了"	可绕过
"位置对了就是人"	脚本能模拟
"越难越安全"	误伤真实用户
"token 可复用"	必须一次性
"验证码能替代风控"	只是其中一层

6. 自检

四道校验分别挡什么？
为什么"只校验位置"不够？
难度该用什么指标定？
token 为什么必须一次性？
验证码与风控的关系？

7. 下一篇

S27-J04 · AOP 与对象转换：代理、拦截、MapStruct

风控讲完，下一篇讲"减少样板代码"的两条路。

本篇属于系列《S27 · 杂项归档与工具实测》。旧文来源：A-405；扩展点 E-S27-013。