Beego 中需通过全局中间件实现接口签名验证，而非仅依赖 Prepare()；校验时须统一时间戳窗口、按字典序拼接含 timestamp/nonce/app_id/业务参数的签名原文，用环境变量加载 secret，并剔除空值字段，失败时记录脱敏请求体并返回标准错误。
Beego 中如何实现接口签名验证（sign）
Beego 本身不内置接口签名（sign）逻辑，必须手动在 Prepare() 方法或中间件中实现。签名验证不是身份认证替代品，而是防重放、防篡改的第一道防线，尤其在开放 API 或支付回调场景里不能跳过。
典型签名流程是：客户端按约定规则拼接参数 → 按指定哈希算法（如 hmac-sha256）计算摘要 → 将摘要作为 sign 字段传入；服务端复现相同拼接与计算，比对结果。
- 必须统一时间戳容忍窗口（如 ±300 秒），用
c.Ctx.Input.Header("X-Timestamp")或请求参数读取，拒绝超时请求 - 签名原文必须包含时间戳（
timestamp）、随机串（nonce）、AppID（app_id）和所有业务参数（按字典序排序后拼接） - 密钥（
secret）绝不能硬编码在代码里，应从环境变量或配置中心加载，例如os.Getenv("API_SECRET") - Beego 的
c.Input().GetStrings()和c.Input().Get()不自动过滤空参数，需手动剔除sign、timestamp、nonce、app_id外的空值字段，否则拼接结果不一致
为什么不能只靠 Prepare() 做签名校验
Prepare() 是控制器级预处理，适合做登录态检查，但签名验证需要更早介入——比如在反向代理之后、路由匹配之前就拦截非法请求，避免无意义的路由解析和 controller 初始化开销。
真正健壮的做法是注册全局中间件，用 beego.InsertFilter("/api/*", beego.BeeApp.FilterType, signVerifyFilter)，确保所有 /api/ 下路径都经过校验，且能在 signVerifyFilter 中直接调用 c.Abort(401) 终止流程。
- 如果只在
Prepare()里做，某些未继承公共基类的 controller 可能漏校验 -
Prepare()执行时已进入具体 controller 上下文，无法统一返回标准错误格式（如{"code":401,"msg":"invalid sign"}） - 签名失败应记录原始请求体（注意脱敏），但 Beego 默认不缓存 request body，需提前用
c.Ctx.Input.CopyBody(1 保留
常见签名失败原因和调试技巧
90% 的签名失败不是算法问题，而是参数拼接细节不一致。最常踩的坑是 URL 编码处理和参数顺序。
- 客户端用
encodeURIComponent编码，服务端用url.QueryEscape——二者行为不完全等价，建议服务端统一用url.Values.Encode()构造标准 query string - 参数键名大小写敏感（如
AppIdvsapp_id），必须和文档严格一致；Beego 的c.Input().Get("app_id")对 key 大小写敏感 - GET 和 POST 需分别提取参数：
c.Input().Get()只读 URL 参数，c.GetString()默认读 POST 表单，JSON Body 需先c.ParseForm()或手动ioutil.ReadAll(c.Ctx.Request.Body) - 调试时可打印签名原文（脱敏后）和 hex 编码后的摘要，与客户端日志逐字符比对，不要只看最终布尔结果
签名与 JWT Token 如何共存
签名验证和 JWT 是两层事：签名保传输安全，JWT 保身份可信。实际项目中往往两者并存——先验签，再验 token。
关键点在于执行顺序：必须签名通过后才解析 JWT，否则攻击者可绕过签名直接发恶意 token。Beego 中推荐把 JWT 解析逻辑放在签名中间件之后的另一个中间件里，或者在 controller 的 Prepare() 中做（前提是签名中间件已保证上下文可信）。
- JWT 的
iss（issuer）字段应与签名中的app_id一致，用于双向校验归属 - 不要把签名密钥和 JWT 签名密钥混用，二者生命周期和分发方式完全不同
- 如果用
beego.SessionOn = true，注意 session cookie 不参与签名计算，签名只覆盖 API 显式参数
