beego中需手动解析authorization头的bearer token：先用strings.split拆分并校验前缀为"bearer"且长度为2，再trimspace提取token；须用自定义struct匿名嵌入jwt.standardclaims并标注json标签；错误须类型断言*jwt.validationerror并按位判断具体原因；密钥应从app.conf读取且长度≥32字节。
Beego中解析Authorization Header里的Bearer Token
Beego默认不自动提取Authorization头中的JWT，必须手动读取并拆分。常见错误是直接用c.Ctx.Input.Header("Authorization")拿到字符串后没做校验就解析，结果遇到空值、格式错（如Bearer tokenxxx少空格）或非Bearer类型时panic。
正确做法是先切分再校验前缀：
- 用
strings.Split(authString, " ")拆成两段，检查长度是否为2 - 确认
kv[0]严格等于"Bearer"（注意大小写） - 丢弃
kv[1]前后空白：strings.TrimSpace(kv[1]) - 若任一条件失败，立即返回
401 Unauthorized，不要继续调jwt.Parse
用jwt.StandardClaims还是自定义struct声明？
直接用jwt.MapClaims最省事，但类型不安全、IDE无提示、字段拼错难发现；用自定义struct（如MyCustomClaims）能编译期校验，且方便嵌入jwt.StandardClaims复用expiatiss等标准字段。
关键点：
- 自定义结构体必须**匿名嵌入**
jwt.StandardClaims，否则jwt.ParseWithClaims无法识别过期逻辑 - 字段标签要用
json:而非form:或xml:，否则解析payload时字段映射失败 - 如果存用户ID，建议用
int64或string，避免int在32/64位系统上行为不一致
jwt.Parse验证失败却没报具体错误原因
调用jwt.Parse后只检查err != nil不够——它可能返回*jwt.ValidationError，而该错误内部有Errors位掩码，比如jwt.ValidationErrorExpired和jwt.ValidationErrorSignatureInvalid含义完全不同，但都表现为err != nil。
必须显式类型断言并分支处理：
- 用
if ve, ok := err.(*jwt.ValidationError); ok判断是否为验证错误 - 再用
ve.Errors & jwt.ValidationErrorExpired != 0区分过期还是签名错 - 过期返回
401，签名错应记日志并返回401（防止信息泄露），别混为一谈
密钥硬编码在代码里 vs 从app.conf读取
开发时图快写死[]byte("my-secret-key")没问题，但上线必须从配置读——Beego的beego.AppConfig.String("jwtkey")是标准方式。容易被忽略的是：密钥长度会影响HS256安全性，len(key) 时实际强度不足。
建议操作：
- 在
app.conf里设jwtkey = "a-very-long-secret-key-32-bytes-min" - 启动时校验
len([]byte(key)) >= 32，不满足则panic，不静默降级 - 别用
time.Now().Unix()之类动态值拼密钥，会导致重启后所有token失效
