go微服务短信防刷需在请求入口、验证码生成、发送链路三环节协同防御：入口按脱敏手机号用sync.map隔离rate.limiter限流；验证码须用crypto/rand生成并加盐哈希存redis，设ex nx过期；发送前统一返回“已提交”，失败日志仅存手机号哈希，高频异常ip自动短时黑名单。
Go 语言构建短信微服务时，防刷不是加个限流中间件就能完事的——关键得在请求入口、验证码生成、发送链路三个环节做协同防御，否则攻击者绕过某一层就失效。
如何用 rate.Limiter 在 HTTP 入口做请求频控
别直接套用全局 rate.NewLimiter，得按手机号维度隔离限流，否则一个恶意号码刷爆配额会误伤正常用户。
- 用
sync.Map缓存每个手机号对应的*rate.Limiter实例，key 是脱敏后的手机号（如138****1234），避免内存无限增长 - 限流参数建议设为
rate.Every(5 * time.Minute)和burst=3，兼顾用户体验和防撞库能力 - 注意：如果用 Redis 做分布式限流，
redis-cell比自实现 Lua 脚本更可靠，但 Go 客户端要显式调用Eval并处理ERR返回值
为什么验证码必须用 crypto/rand 生成而非 math/rand
math/rand 是伪随机，种子固定时输出可预测；短信验证码一旦被暴力穷举，等于把登录凭证直接暴露。
- 生成 6 位数字验证码时，用
crypto/rand.Read()配合big.Int取模，不要用rand.Intn(1000000) - 验证码必须带过期时间（如
5 * time.Minute），且写入 Redis 时用SET key value EX 300 NX，防止覆盖已发码 - Redis 中存储的验证码值建议加盐哈希（如
sha256(phone + code + secret)），避免缓存击穿后明文泄露
发送前校验失败时，为什么不能直接返回错误给客户端
返回 "验证码错误" 或 "发送太频繁" 这类提示，等于帮攻击者做条件判断，会加速撞库或探测。
- 统一返回
{"code": 0, "msg": "已提交"}，无论校验通过与否——真实结果异步落库或发消息队列 - 记录日志时，只记手机号哈希（如
sha256(phone)）和操作类型，不记原始手机号和验证码明文 - 对高频失败请求（如 1 小时内同一 IP 失败 >20 次），自动触发 IP 加入临时黑名单，但黑名单 TTL 必须设短（如 15 分钟），避免误封
怎么让短信通道本身不成为防刷瓶颈
运营商网关响应慢或限频，会导致你的服务线程卡死，反而放大攻击效果。
- 调用第三方短信 SDK 时，必须设置
context.WithTimeout(ctx, 3*time.Second)，超时立即放弃，不重试 - 用
chan struct{}控制并发数（如最多 50 个并发请求），避免突发流量打崩下游 - 短信发送结果回调必须幂等：收到重复回调时，只更新状态为
"sent"，不重复计费或触发业务逻辑
真正难的不是写几个限流函数，而是让所有环节对异常请求“装作什么都没发生”——防刷的本质是增加攻击者的不确定性，而不是追求 100% 拦截。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
