Beego需手动实现请求签名验证中间件，核心是在FilterType中拦截请求，提取sign/timestamp/nonce，按method+path+query_string+body_hash+timestamp+nonce顺序拼串并用共享密钥验签，须校验时间戳防重放，GET时body_hash为空，POST前需CopyBody。
Beego 中间件如何做请求签名验证
Beego 本身不提供内置的签名验证中间件，必须手动实现。核心是拦截请求、提取签名参数（如 sign、timestamp、nonce），按约定规则拼接待签名字符串，再用共享密钥验签。不能依赖框架自动解析或校验。
- 签名逻辑必须放在
beego.BeeApp.FilterType（即路由前）注册的中间件中，确保在控制器执行前完成校验 - 验签失败时应直接调用
ctx.Abort(401, "Unauthorized")并return，避免继续执行后续逻辑 - 务必校验
timestamp是否在合理时间窗口内（如 ±5 分钟），防止重放攻击；建议用time.Now().Unix()对比，而非本地时钟 - 待签名字符串拼接顺序必须与客户端严格一致：通常为
method + path + query_string + body_hash + timestamp + nonce，其中body_hash需对原始 request body 计算 SHA256（注意：Beego 的ctx.Input.RequestBody只在ParseForm()或显式读取后才可用） - 若接口允许 GET/POST 混用，需统一处理：GET 无 body，
body_hash固定为空字符串；POST 则需提前ctx.Input.CopyBody(1 缓存 body，否则后续 controller 无法再读
为什么不能在控制器里做签名验证
把签名校验逻辑写进 controller 方法，等于放弃中间件的核心价值——复用性与前置拦截能力。更严重的是，此时 session、参数绑定、CSRF token 等前置 filter 可能已修改 ctx 状态，导致签名原文不一致（比如 query 被 decode 过、body 被 parse 成 map 后丢失原始顺序）。
- Beego 的
ParseForm()会自动解析application/x-www-form-urlencoded和multipart/form-data，但会丢弃原始字节流，使签名原文不可还原 - 如果签名依赖 URL query，而你又用了
beego.RESTRouter，路径参数（如/user/:id）会被替换，原始ctx.Request.URL.String()已非客户端所发 - 正确做法是：在中间件中用
ctx.Request.URL.Path+ctx.Request.URL.RawQuery+ctx.Input.RequestBody构建原始请求快照
如何安全获取和哈希请求 Body
Beego 默认不缓存请求体，ctx.Input.RequestBody 初始为空切片。直接读 ctx.Request.Body 会导致后续 controller 读不到数据 —— 这是最常踩的坑。
- 必须在中间件开头调用
ctx.Input.CopyBody(1（参数为最大缓存字节数），之后才能安全使用 <code>ctx.Input.RequestBody - 不要用
ioutil.ReadAll或io.ReadAll直接读ctx.Request.Body，这会消耗流且不可重置 - 若 body 超过缓存上限，
CopyBody会截断，此时应直接Abort(400, "Body too large")，避免验签绕过 - 计算 hash 前检查
len(ctx.Input.RequestBody) > 0，空 body 对应空字符串参与签名拼接
签名密钥怎么管理才不硬编码
把密钥写死在中间件函数里等于裸奔。Beego 提供了配置层支持，应从 conf/app.conf 加载，并在运行时校验非空。
- 在
app.conf中添加：api_sign_key = "your-32-byte-secret-here" - 中间件中通过
beego.AppConfig.String("api_sign_key")获取，启动时检查返回值是否为空，为空则 panic - 生产环境禁止用默认 key 或明文写在 git 里；建议用环境变量注入：
api_sign_key = ${API_SIGN_KEY}，再由部署流程注入 - 若需多租户不同密钥，可从请求 header（如
X-Api-Key）查数据库或 Redis 获取对应密钥，但要注意该查询本身不能成为性能瓶颈
+ 为空格），签名就必然失败。 
