Echo中CSRF Cookie防御不自动生效，需显式配置TokenLookup为"cookie:csrf"才能从Cookie读取token；默认仅检查X-CSRF-Token请求头，且Cookie必须设Secure=true（HTTPS）、SameSite=Lax、HTTPOnly=false，并与Session Cookie域和路径一致。
CSRF Cookie防御在Echo里不是自动生效的
直接启用 middleware.CSRFWithConfig 并不能让Cookie自动参与校验——它只负责生成和写入Cookie，但默认不从Cookie读取token。如果你期望前端通过 X-CSRF-Token 头或表单字段提交，而服务端却去比对Cookie里的值，那必须显式配置 TokenLookup 为 "cookie:csrf" 或类似形式，否则校验永远失败。
必须手动配 TokenLookup 才能从 Cookie 读 token
默认的 TokenLookup 是 "header:X-CSRF-Token"，这意味着中间件只检查请求头。要让它从 Cookie 读，得明确指定：
-
TokenLookup: "cookie:csrf"—— 对应CookieName: "csrf"（默认值） - 若自定义了 Cookie 名，比如
CookieName: "my_csrf_token"，则TokenLookup必须同步改为"cookie:my_csrf_token" - 注意：Cookie 值是 base64 编码的 token，
gorilla/csrf和echo/middleware都会自动解码，你不用手动处理
Cookie 属性必须匹配 SameSite + Secure 才可靠
仅靠 Cookie 存 token 不够，浏览器是否自动携带它，取决于 Cookie 属性设置：
-
CookieSecure: true—— 强制 HTTPS 下才发送，HTTP 环境下 token 不会被带上 -
CookieSameSite: http.SameSiteLaxMode—— 推荐用于大多数表单场景；Strict过于激进，可能导致用户从站外链接进入时丢失 token -
CookieHTTPOnly: false—— 必须设为false，否则前端 JS 拿不到 cookie 值（除非你只走 header 注入，不依赖 JS 读取）
漏掉 SameSite 或误设 Secure 在 HTTP 环境，会导致 token Cookie 根本不被浏览器发送，后端收不到任何值，所有非幂等请求直接 403。
CSRF Cookie 和 Session Cookie 要共域且路径兼容
CSRF 中间件生成的 Cookie 必须能和你的 Session Cookie 同时被浏览器附带，否则校验时找不到 session 上下文：
- 确保
CookieDomain和 Session 中间件（如gorilla/sessions）的Options.Domain一致，例如都设为".example.com" -
CookiePath默认为空，即 "/"，推荐显式设为"/"，避免子路径下 token 不可见 - 如果 Session 存在子路径（如
/admin），而 CSRF Cookie Path 是/api，那么 API 请求可能拿不到 session，导致 token 校验失败
最常被忽略的是域和路径的隐式不匹配——看起来都“能跑”，但某次部署改了反代规则或子域名后，CSRF 突然失效，查半天才发现 Cookie Path 被 Nginx 重写了。
