secure中间件需手动安装注册，非echo内置；必须用go get github.com/unrolled/secure安装并导入该路径，secure.new()配置需权衡各header策略兼容性，且必须置于所有可能修改header的中间件之后生效。
Secure中间件必须手动安装并显式注册，Echo本身不内置它；直接用secure.New()初始化后挂载到路由链即可生效，但Header策略选错或顺序放错会导致安全头被覆盖。
为什么secure不是Echo默认中间件
Echo核心只提供路由、Context和基础中间件（如Logger、Recover），secure是独立维护的第三方包，需单独引入：
- 安装命令必须是
go get github.com/unrolled/secure（注意不是labstack组织下的） - 导入路径为
github.com/unrolled/secure，不是echo/middleware - 若误用
echo.Use(middleware.Secure(...))会编译失败——因为Echo v4里根本没这个函数
secure.New()配置项关键取舍
不同安全头作用域和兼容性差异大，硬编码全开反而可能破坏现有功能：
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
-
FrameDeny: true会强制加X-Frame-Options: DENY，但现代浏览器更推荐Content-Security-Policy: frame-ancestors 'none'，二者共存时后者优先级更高 -
ContentTypeNosniff: true在某些老旧IE场景下可能导致JS/CSS加载失败，若服务包含遗留前端建议关掉 -
SSLRedirect: true仅在反向代理（如Nginx）已终止HTTPS且传了X-Forwarded-Proto: https时才安全启用，否则会无限重定向 -
ReferrerPolicy: "strict-origin-when-cross-origin"比默认"no-referrer-when-downgrade"更隐私，但部分分析工具依赖完整Referer字段
中间件注册顺序直接影响Header是否生效
HTTP响应头由最后一个写入者决定，secure必须放在所有可能修改Header的中间件之后：
- 错误顺序：
e.Use(middleware.Logger())→e.Use(secure.New(...))→e.Use(customHeaderMiddleware)→customHeaderMiddleware可能覆盖secure写的Content-Security-Policy - 正确顺序：
e.Use(middleware.Logger())→e.Use(customAuthMiddleware)→e.Use(secure.New(...))→ 所有业务中间件执行完，secure最后统一注入安全头 - 若用了
echo.HTTPErrorHandler自定义错误处理，确保它不提前WriteHeader，否则secure的Header会丢失
最易被忽略的是secure对OPTIONS预检请求的静默处理——它默认不给预检响应加安全头，如果API要支持CORS且要求严格安全策略，得额外用middleware.CORSWithConfig补全，不能只靠secure。
