必须用jwt.parsewithclaims并显式传入密钥和claims结构体，解析后须校验token.valid且做错误类型断言；keyfunc需校验算法、返回合规[]byte密钥，自定义claims必须嵌入jwt.registeredclaims并用json tag映射字段。
怎么用 golang-jwt 解析并验证 JWT 字符串
直接调用 jwt.Parse 不行——它只做基础解析，不校验签名。必须传入密钥和验证函数，否则返回的 *Token 可能 Valid == false，但你根本不知道是签名错、过期还是算法不匹配。
典型做法是用 jwt.ParseWithClaims，显式传入密钥和 jwt.Claims 实现（比如 jwt.MapClaims 或自定义结构体），并在 keyFunc 中返回密钥：
token, err := jwt.ParseWithClaims(tokenString, &MyClaims{}, func(t *jwt.Token) (interface{}, error) {
if _, ok := t.Method.(*jwt.SigningMethodHMAC); !ok {
return nil, fmt.Errorf("unexpected signing method: %v", t.Header["alg"])
}
return []byte("your-secret-key"), nil
})
if err != nil || !token.Valid {
// 错误处理：可能是签名无效、过期、算法不支持等
}
-
keyFunc必须返回interface{}类型密钥，HMAC 用[]byte，RSA 用*rsa.PublicKey - 别在
keyFunc里硬编码密钥，生产环境应从配置或密钥管理服务加载 - 如果 JWT 是 RS256 签名，
keyFunc返回公钥时，务必确保 PEM 格式正确且未被截断
为什么解析后 Claims 为空或字段丢失
常见原因是没指定正确的 Claims 类型，或结构体字段没加 JSON tag。golang-jwt 默认用 jwt.MapClaims，但如果你用自定义结构体，字段必须导出且带 json: tag，否则反序列化失败：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
type MyClaims struct {
UserID string `json:"user_id"`
Role string `json:"role"`
jwt.RegisteredClaims
}
-
jwt.RegisteredClaims必须嵌入，否则ExpiresAt、IssuedAt等标准字段不会被自动填充 - 字段名大小写要和 JWT payload 里的 key 完全一致（包括下划线/驼峰），JSON tag 是唯一映射依据
- 如果 payload 里有非字符串字段（比如
"exp": 1717023600），结构体对应字段类型必须是int64或float64，不能是string
如何区分签名错误、过期、Issuer 不匹配这些具体错误
jwt.ParseWithClaims 的 err 是通用 error，但你可以用类型断言提取更细粒度原因：
if errors.Is(err, jwt.ErrSignatureInvalid) {
// 签名验证失败
} else if errors.Is(err, jwt.ErrTokenExpired) {
// token 已过期
} else if errors.Is(err, jwt.ErrTokenNotValidYet) {
// 尚未生效（nbf）
} else if errors.As(err, &jwt.ValidationError{}) {
// 其他验证失败，比如 issuer 不匹配、audience 不符
}
-
errors.Is比strings.Contains(err.Error(), "...")可靠得多，避免字符串匹配误判 - 自定义验证逻辑（如检查
Issuer）应在keyFunc之后、ParseWithClaims返回前完成，不要依赖token.Claims再做二次判断 - 注意：
jwt.ValidationError的Errors字段是位掩码，可用&判断组合错误（如err.Errors & jwt.ValidationErrorExpired != 0）
golang-jwt 和 github.com/dgrijalva/jwt-go 有什么关键区别
旧库 github.com/dgrijalva/jwt-go 已归档，存在已知安全问题（如算法混淆漏洞），新项目必须用 github.com/golang-jwt/jwt/v5（注意 v5 后缀）。主要差异点：
- v5 把
Parse拆成ParseWithClaims，强制你明确声明 Claims 类型，减少隐式错误 - v5 默认禁用
none算法，旧库需手动过滤；v5 的SigningMethodNone已移除 - v5 的
Valid字段只在签名和时间验证都通过后才为 true，旧库可能因 panic 导致Valid值不可靠 - 导入路径变了：
import "github.com/golang-jwt/jwt/v5"，不是jwt，v5 中所有类型都带v5.前缀（如v5.SigningMethodHS256）
最易忽略的是版本路径和 SigningMethod 常量命名——写错路径或漏掉 v5. 会导致编译失败或静默降级到旧行为。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
