直接用SetCookie无法防伪，因其仅原样写入响应头且不签名；需用echo.NewSignedCookie配合NewHTTPCookie实现HMAC-SHA256签名（value|signature格式），并仅通过c.GetCookie自动验签读取。
为什么直接用 SetCookie 无法防伪？
因为 http.SetCookie 或 Echo 的 c.SetCookie() 只是原样写入 Set-Cookie 响应头，不处理签名。浏览器发回的 Cookie 值完全由客户端控制，服务端若直接信任 req.Cookie("auth") 的原始值，就等于把校验逻辑交给了用户——这和裸奔没区别。
用 echo.NewHTTPCookie + echo.NewSignedCookie 才算真正签名
Echo 自带签名支持，但必须走它的 Cookie 构造链，不能手动拼接。核心是：服务端用密钥对 Cookie 值做 HMAC-SHA256 签名，把签名附加在值末尾（格式为 value|signature），读取时自动验证。
实操要点：
-
echo.NewSignedCookie必须配合echo.NewHTTPCookie使用，不能直接传给c.SetCookie() - 签名密钥需全局复用，建议从环境变量加载，长度至少 32 字节（
crypto/rand.Reader生成） - Cookie 名称不能含点（
.）或空格，否则签名验证会静默失败 - 签名只保护
Value字段，Path、Domain等元数据不参与计算，也不受保护
示例：
cookie := echo.NewHTTPCookie()
cookie.Name = "session_id"
cookie.Value = "abc123"
cookie.Path = "/"
cookie.HTTPOnly = true
cookie.Secure = true // 生产环境务必开启
cookie.MaxAge = 3600
signed := echo.NewSignedCookie(cookie, []byte("your-32-byte-secret-key-here"))
c.SetCookie(signed)
c.GetCookie 和 c.Cookie 的行为差异
Echo 提供两个读 Cookie 方法，但只有 c.GetCookie 会自动验证签名并剥离签名部分；c.Cookie 是原始 net/http 行为，返回未解包的完整字符串（含 |signature 后缀）。
常见错误：
- 用
c.Cookie("session_id")拿到"abc123|e8f1a7..."，再手动strings.Split()—— 这绕过了签名验证逻辑，等同于没签名 - 没检查
c.GetCookie的 error 返回：验证失败时它返回http.ErrNoCookie或自定义错误，不是 nil - 密钥变更后旧 Cookie 全部失效，但错误信息不提示“签名无效”，只表现为空值，容易误判为用户未登录
签名 Cookie 的实际限制与替代思路
签名只解决“值未被篡改”，不解决重放、劫持、有效期绕过等问题。比如：
- 攻击者截获一个有效的
session_id|sig，仍可重复提交（无一次性 nonce） - Cookie 设置了
MaxAge=3600，但签名本身不阻止用户手动改时间续期 - 敏感字段（如 user_id）不该明文塞进 Cookie，签名只是加了层锁，钥匙还在服务端
真要防重放，得结合服务端 Session 存储 + 时间戳/nonce 校验；真要防泄露，优先上 SameSite=Strict 和 Secure，而不是只靠签名。
签名密钥轮换、多实例间密钥同步、签名算法升级（如从 SHA256 切到 SHA512）这些细节，文档几乎不提，但线上出问题时全得自己兜底。
