密钥不能硬编码或从环境变量直接读字符串转[]byte，必须用Base64编码的32字节随机密钥，由Vault等密钥服务注入并解码；KeyFunc需预加载缓存、校验解码错误并打日志，避免静默401。
密钥不能硬编码或从环境变量直接读字符串
直接写 []byte("my-secret") 或用 os.Getenv("JWT_SECRET") 拿字符串再转 []byte，是生产环境最常见崩盘点。环境变量一旦被日志打印、调试输出或错误堆栈泄露，整个 JWT 体系就等于裸奔。
真正安全的做法是：密钥本身必须是 Base64 编码的随机字节序列，且由外部可信源注入——不是靠代码拼接，也不是靠启动时读字符串。
- 开发阶段可用
openssl rand -base64 32生成 32 字节密钥（解码后长度为 32），存入.env文件并加入.gitignore - 生产环境必须走密钥管理服务（如 HashiCorp Vault、AWS Secrets Manager），启动时拉取 Base64 字符串，再用
base64.StdEncoding.DecodeString()解码为[]byte - 绝对不要在 KeyFunc 里做
return []byte(secret)—— 如果secret是未校验的环境变量字符串，空格、换行、BOM 都会导致签名失败
HS256 密钥长度和生成方式有硬性要求
jwt.SigningMethodHS256 对密钥长度敏感：低于 32 字节会显著降低抗暴力破解能力；高于 64 字节不提升安全性，但可能触发某些底层库警告。Go 标准库的 hmac.New 不检查长度，但实际安全边界很明确。
- 推荐固定生成 32 字节原始密钥，Base64 编码后长度为 44 字符（含等号）
- 避免用
crypto/rand.Read自己拼字符串——容易漏掉填充、编码、校验逻辑 - 别用
Keys.secretKeyFor(SignatureAlgorithm.HS256)（Spring 风格），Echo 中没有该封装；直接用Decoders.BASE64.decode()的 Go 等效实现即可
Echo-jwt 中 SigningKey 必须是 []byte，且不能动态重算
echojwt.Config.SigningKey 类型是 interface{}，但实际只接受 []byte 或返回 []byte 的 jwt.Keyfunc。很多同学误传 string，导致签名校验永远失败，错误却不明显。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 正确写法：
SigningKey: []byte(decodedKeyBytes)，其中decodedKeyBytes是已解码的[]byte - 若需多密钥轮换（如旧密钥未过期、新密钥已上线），必须用
KeyFunc，且函数内不能每次调用都重新解码或读文件——应预加载并缓存 - 别在
KeyFunc里调os.Getenv+base64.DecodeString—— 高并发下重复解码浪费 CPU，且无法处理解码失败（会 panic）
为什么 KeyFunc 返回 nil 会导致 401 却不报错原因
当 echojwt.Config.KeyFunc 返回 nil, nil 或 nil, err，中间件默认静默拒绝请求（HTTP 401），但不会透出具体失败点。这是最隐蔽的调试陷阱。
真实场景中，KeyFunc 常因以下原因返回 nil：
- 从 Vault 获取密钥超时，没设 fallback 或 panic 处理
- Base64 解码失败（比如环境变量末尾多了换行符），但代码里没检查
err != nil - 密钥版本匹配逻辑出错，例如 token header 带
"kid": "v2"，但KeyFunc查不到对应密钥就直接 return nil
务必在 KeyFunc 开头加日志，打印 kid、尝试加载的密钥 ID、解码是否成功——否则你只会看到“token invalid”，却不知道密钥根本没加载进来。
