Secure中间件需手动安装github.com/unrolled/secure，导入后必须传非nil的secure.Options{}初始化，且e.Use()须在路由注册前调用；它不处理HTTPS重定向，需显式配置SSLRedirect并确保代理透传X-Forwarded-Proto。
Secure中间件必须手动安装，不能直接用echo/middleware
Secure不是Echo内置中间件，它来自独立包github.com/unrolled/secure（注意不是labstack/echo-jwt那种同源生态）。不手动go get就调用会报undefined: secure.New。官方文档里没提这点，新手常卡在这一步。
安装命令：
go get github.com/unrolled/secure
导入时别写错包名：import "github.com/unrolled/secure"，不是"github.com/labstack/echo/v4/middleware"。
初始化Secure必须传secure.Options{}，空结构体也不行
直接secure.New()会panic，因为底层强制要求Options非nil。哪怕你只想开一个头，也得显式传空结构体：
secureMiddleware := secure.New(secure.Options{})
常见错误现象：panic: runtime error: invalid memory address or nil pointer dereference，就因为漏了secure.Options{}。
真正启用某项防护时，改对应字段即可，比如防点击劫持：
secureMiddleware := secure.New(secure.Options{
FrameDeny: true,
})
X-Frame-Options和CSP不能混用同一实例
secure.Options里FrameDeny、CustomFrameOptionsValue和ContentSecurityPolicy是互斥配置项。如果同时设FrameDeny: true和ContentSecurityPolicy: "frame-ancestors 'none';"，后者会被忽略——Secure优先走X-Frame-Options逻辑。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
实际选型建议：
- 老浏览器兼容性要求高 → 用
FrameDeny: true - 需要细粒度控制iframe来源（如只允某些域名嵌入）→ 改用
CustomFrameOptionsValue: "ALLOW-FROM https://trusted.com" - 现代应用且已用CSP → 直接配
ContentSecurityPolicy，关掉FrameDeny
重复设置不仅无效，还会让安全策略意图模糊，审计时难追溯。
注册顺序影响Header是否生效
Secure中间件必须在路由注册之前调用e.Use()，否则响应头不写入。典型反模式：
e.GET("/health", handler)
e.Use(secureMiddleware) // ❌ 晚了，/health响应不会带安全头
正确顺序：
e.Use(secureMiddleware) // ✅ 全局生效
e.GET("/health", handler)
如果只对部分路由加安全头（比如仅API路径），得用路由组+单独注册：
api := e.Group("/api")
api.Use(secureMiddleware)
api.GET("/v1/users", handler)
但注意：这种写法下，/api以外的路径（如/static）完全不受Secure保护，得额外补漏。
最易被忽略的一点：Secure不处理HTTPS重定向。如果你的站点跑在HTTP端口但期望强制跳转HTTPS，得自己加secure.Options{SSLRedirect: true}，且确保反向代理（如Nginx）已透传X-Forwarded-Proto，否则会无限重定向。
