OTP验证失败总是返回false，根本原因在于密钥未按RFC 4226要求做base32解码、时间窗口未启用skew容错、二维码URI参数缺失或编码错误，以及并发下time.Now()精度不足导致窗口错位。
OTP验证失败总是返回false？检查hotp.Compute()的时间窗口和密钥编码
Go里用github.com/pquerna/otp做OTP，最常见问题是hotp.Verify()或totp.Validate()始终返回false。根本原因往往不是逻辑错，而是密钥没按RFC 4226要求做base32解码。
- 密钥必须是原始字节（如从
base32.StdEncoding.DecodeString("GEZDGNBVGY3TQOJQ")得到），不能直接传入base32字符串 -
totp.Validate()默认时间步长是30秒，但客户端（如Google Authenticator）可能因系统时间偏差导致校验失败，建议用totp.WithSkew(1)允许前后各1个时间窗口 - 使用
hotp.Compute()生成测试码时，计数器值必须和客户端同步；调试阶段可用totp.GenerateCodeCustom()指定时间戳快速比对
生成TOTP二维码时URL参数写错会导致扫码失败
二维码内容本质是URI，格式为otpauth://totp/Issuer:User?secret=...&issuer=...&algorithm=SHA1&digits=6&period=30，漏掉任意必需参数都会让Authenticator拒绝导入。
-
secret参数值必须是base32编码后的字符串（不是原始字节），且+和/要URL编码成%2B和%2F -
issuer和账户名之间用冒号分隔，且整个issuer字段需URL编码，否则部分App会截断 - 别省略
algorithm和digits——即使默认SHA1/6位，显式声明可避免某些旧版客户端兼容问题
并发场景下TOTP验证出现“偶发性失败”？注意time.Now()精度和时钟漂移
在高并发服务中，多个goroutine几乎同时调用totp.Validate()，可能因系统时钟微小抖动（尤其是容器环境）导致同一时间戳落在不同时间窗口，造成验证结果不一致。
- 不要依赖
time.Now().Unix()直接算窗口序号，改用totp.TimeAt(time.Now())获取标准化时间戳 - 若服务部署在NTP未校准的机器上，建议加一层缓存：对同一
code+key组合，在5秒内重复验证直接返回缓存结果（需注意防重放） - 生产环境务必开启NTP同步，
chrony比ntpd在云环境中时钟收敛更快
如何安全存储OTP密钥？避免硬编码或明文写入数据库
OTP密钥等同于第二把密码，一旦泄露即失去双因素意义。Go应用里最常见的错误是把密钥拼接进SQL INSERT语句，或用os.Getenv()直接暴露在环境变量中。
立即学习“go语言免费学习笔记（深入）”；
- 密钥入库前必须用AES-GCM加密，密钥派生用
scrypt.Key()基于主密码生成，主密码从KMS（如AWS KMS、HashiCorp Vault）动态获取 - 绝不在日志中打印完整密钥——哪怕只是调试，也要用
fmt.Sprintf("key_%s", keyID)代替fmt.Printf("%s", key) - 如果用SQLite做本地开发，确保
.db文件权限为0600，且不提交到Git；PostgreSQL建议用pgcrypto扩展在数据库层加密
真正麻烦的不是生成和验证OTP，而是密钥生命周期管理：用户换手机时如何安全迁移、密钥泄露后如何快速失效、备份码怎么生成又不被滥用——这些细节没处理好，再标准的TOTP实现也形同虚设。
