c.Redirect()没生效是因为仅设置响应头而不中断中间件链，必须调用c.Abort()终止后续处理，否则响应可能被覆盖；正确做法是重定向后立即c.Abort()。
中间件里调用 c.Redirect() 为什么没生效？
直接在 Echo 中间件里写 c.Redirect(302, "/login")，浏览器没跳转，请求还继续往下走了。这是因为中间件执行时，响应尚未提交，但 c.Redirect() 只是设置状态码和 Location 头，并不自动终止后续处理链。Echo 不会像路由处理器那样自动结束请求流。
必须显式返回 echo.ErrAbort 或调用 c.Abort() 来中断中间件链，否则后续中间件和最终的 Handler 仍会执行，可能覆盖重定向头或写入响应体，导致跳转失败。
- 正确做法：重定向后立即调用
c.Abort() - 错误写法：
c.Redirect(302, "/login")后无中断，或只写return nil - 注意：
c.Redirect()内部调用的是c.Response().Header().Set("Location", ...)和c.Response().WriteHeader()，但不阻断流程
带条件判断的登录重定向中间件怎么写？
典型场景是未登录用户访问受保护路由时跳转到登录页。关键在于准确判断是否需要重定向，且避免对静态资源、API 接口等误跳转。
推荐用路径前缀 + session/Token 检查组合判断，不要仅依赖 c.Request().URL.Path 做字符串匹配（易漏掉带查询参数的路径）。
- 检查
c.Get("user") == nil（假设你已在前置中间件中把用户存入 context） - 用
strings.HasPrefix(c.Request().URL.Path, "/admin/")判断敏感路径，比正则更轻量 - 排除
/api/和/static/等无需跳转的路径前缀 - 重定向目标建议用绝对路径，避免相对路径在子目录部署时出错
func AuthRedirect() echo.MiddlewareFunc {
return func(next echo.HandlerFunc) echo.HandlerFunc {
return func(c echo.Context) error {
if c.Get("user") == nil &&
strings.HasPrefix(c.Request().URL.Path, "/admin/") &&
!strings.HasPrefix(c.Request().URL.Path, "/api/") {
c.Redirect(302, "/login?redirect="+url.QueryEscape(c.Request().URL.RequestURI()))
c.Abort()
return nil
}
return next(c)
}
}
}
c.Redirect() 的状态码选 301 还是 302？
绝大多数重定向中间件场景该用 302（Found），不是 301（Moved Permanently）。301 会被浏览器和 CDN 强制缓存，一旦配置写错，用户可能长期卡在错误跳转里，连清缓存都未必立刻生效。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
只有当你确认某条路径永久废弃、且所有客户端都应更新书签时，才考虑 301。比如域名迁移后的全局跳转。日常权限控制、登录跳转、A/B 测试路由等，一律用 302 或更明确语义的 303（See Other）。
- POST 请求后重定向，用
303更规范（避免重复提交） - 前端是 SPA 时，有时用
307保留原始请求方法，但中间件中少见 - Echo 的
c.Redirect()默认用302，显式传参更安全：c.Redirect(http.StatusFound, "/login")
重定向后如何保留原始请求参数？
用户从 /admin/orders?id=123&tab=history 被踢到登录页，登录完得自动回到原 URL。中间件里不能只硬编码 "/login"，得拼接 redirect 查询参数。
注意两点：一是用 url.QueryEscape() 编码原始路径，否则含 & 或 = 会破坏 URL 结构；二是避免多次嵌套编码（比如已编码过的 URL 再套一次），建议只在中间件里做一次干净编码。
- 获取原始路径用
c.Request().URL.RequestURI()（含查询参数），不是Path - 不要手动拼字符串，用
url.ParseQuery+url.Values构造更健壮（尤其多参数时） - 如果登录接口本身也接收
redirect参数，确保它做了白名单校验，防止开放重定向漏洞
真正容易被忽略的是：重定向中间件通常放在认证中间件之前，但如果你把用户信息塞在 c.Set() 里又没在重定向前检查，就会误判——务必保证权限判断逻辑在重定向中间件内部完成，不依赖下游中间件的副作用。
