Echo框架路由重定向必须走HTTP 3xx响应，核心是中间件全局跳转（如e.Pre(middleware.HTTPSRedirect())）或handler内调用c.Redirect()并紧跟return，否则会因headers已发送而报错。
Echo 框架里做路由重定向，别用 router.push 或前端跳转那一套——它压根没这玩意儿。重定向必须走 HTTP 3xx 响应，核心就两条路：中间件全局跳转，或 handler 内手动调用 c.Redirect()。
用 middleware.HTTPSRedirect() 强制跳转 HTTPS
这是最典型的生产环境需求：所有 HTTP 请求自动升到 HTTPS。它只在请求进入路由前生效，不依赖具体路径，也不执行后续 handler。
- 必须放在
e.Pre()里，不是e.Use()；放错位置会导致重定向被绕过 - 默认只处理
http://开头的请求，对本地开发用http://localhost:8080无效（浏览器会拒绝非安全上下文的自动升级） - 如果反向代理（如 Nginx）已终止 SSL，需额外配置
X-Forwarded-Proto头，并启用middleware.HTTPSRedirectWithConfig()的TrustProxy选项，否则永远卡在 HTTP
在 handler 中调用 c.Redirect() 实现动态跳转
适合登录后跳回原页面、表单提交成功后跳转等需要逻辑判断的场景。和 Gin 不同，Echo 的 c.Redirect() 默认不会中断执行，漏掉 return 就会报 write to body after headers sent。
- 签名是
c.Redirect(statusCode int, url string)，比如c.Redirect(302, "/dashboard") - 必须紧跟
return，写成return c.Redirect(...)，否则后续代码照常运行 - 状态码别乱选：301 表示永久重定向，会被浏览器缓存；302 是临时跳转，更安全；307/308 能保留原始请求方法（POST 不变），但兼容性略差
- 跳转目标支持相对路径（
"/login"）、绝对路径（"https://example.com"），但不支持前端路由式 hash 路径（"/#settings"）——那是浏览器行为，服务端发出去的 URL 里 # 后内容根本不会被发送
WWW 与非 WWW 域名统一跳转
比如把 example.com 全部导向 www.example.com，或反过来。Echo 提供了开箱即用的中间件，但行为很“刚”——它不区分协议，也不管你有没有配好 DNS。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
-
middleware.WWWRedirect()把无 www 的请求加 www；middleware.NonWWWRedirect()则相反（注意：文档里写的HTTPSWWWRedirect()是组合版，不是基础中间件） - 这两个中间件只检查 Host 头，不验证证书或反向代理设置；如果你用 Cloudflare 或 CDN，Host 头可能已被改写，得配合
TrustProxy配置 - 它们对
localhost或 IP 直连完全无效，开发时测试要切真实域名
重定向后为什么页面空白或报错？
最常见的三个原因都跟响应生命周期有关：头已发送、路径错误、中间件顺序错。
-
Headers already sent：在c.Redirect()前用了c.String()、c.JSON()或任何输出类方法，哪怕只是fmt.Println()打印日志也有可能触发（如果日志写到了 response body） - 跳转 URL 写成
"//example.com"这种协议相对地址，结果在 HTTP 页面里跳到了http://example.com，而你只开了 HTTPS，直接 404 - 把重定向中间件放在
e.Use()里而不是e.Pre()，导致某些路由（比如静态文件）被跳过，或者跳转逻辑被其他中间件拦截
真正麻烦的从来不是怎么写那行 c.Redirect(302, "/home")，而是它发出去之后，请求头里有没有 X-Forwarded-Proto、浏览器认不认那个 Location、反向代理截没截住 302——这些链路环节，一个没对齐，跳转就静默失败。
