在Echo中获取完整Cookie应优先用c.Request().Header.Get("Cookie")读原始头，避免c.Cookie()报错；调试时可正则脱敏敏感字段后打印，生产环境须过滤；SameSite/Secure设置不当会导致Cookie不发送。
如何在Echo中获取并打印完整的Cookie信息
Echo本身不自动记录Cookie日志，必须手动从c.Request().Header或c.Cookie()中提取。直接读Cookie头最可靠，因为c.Cookie(name)只返回单个值且会抛错（如不存在或解析失败），不适合调试。
- 用
c.Request().Header.Get("Cookie")一次性拿到原始字符串，例如"sessionid=abc123; theme=dark; Path=/;" - 若需结构化查看，可调用
http.ParseCookies(c.Request().Cookies())，但注意它会跳过格式异常的Cookie（比如含非法字符） - 别在中间件里用
c.SetCookie()后立刻c.Cookie()读——写入尚未生效，仍得查Header或后续请求
在Logger中间件中安全输出Cookie而不泄露敏感字段
生产环境绝不能原样打Cookie头，必须过滤。Echo的middleware.Logger()默认不包含Cookie，需自定义。
- 用正则匹配并脱敏常见敏感键：对
sessionid、auth_token、remember_token等做***替换 - 避免用
strings.Contains粗筛——user_session_id会被误杀，应以=为界精确分割键值对 - 示例片段：
cookieHdr := c.Request().Header.Get("Cookie") cleaned := regexp.MustCompile(`(?i)(sessionid|auth_token|token)=([^;]+)`).ReplaceAllString(cookieHdr, "$1=***")
为什么c.Cookie("xxx")经常返回"HTTP Error 500: http: named cookie not present"
这不是Echo特有错误，而是Go标准库http.Request.Cookie()抛出的http.ErrNoCookie被Echo转成500。根本原因是：该方法要求Cookie必须符合RFC 6265且未被浏览器标记HttpOnly（其实HttpOnly不影响服务端读取，但会影响某些客户端发送逻辑）。
- 检查浏览器是否真的发送了该Cookie：用
c.Request().Header.Get("Cookie")确认原始头存在 - 确认域名和路径匹配——开发时常见localhost和127.0.0.1被视为不同域，导致Cookie不携带
- 如果用Postman测试，需手动勾选"Send cookies"，否则
Cookie头为空
调试时临时启用全量Header日志的轻量方案
比写完整中间件更快的办法：在路由处理函数开头加一行调试输出，仅用于开发阶段。
log.Printf("[DEBUG] %s %s | Cookie: %s", c.Request().Method, c.Request().URL.Path, c.Request().Header.Get("Cookie"))- 配合
curl -v或浏览器Network面板，交叉验证请求头是否一致 - 上线前务必删掉——频繁
log.Printf在高并发下会拖慢性能，且可能写满磁盘
真正容易被忽略的是Cookie的SameSite属性和Secure标志对开发调试的影响：本地HTTP服务下设Secure=true会导致浏览器拒绝发送Cookie，此时Cookie头永远为空，但错误日志里不会提示，只能靠抓包确认。
