go 的 http.cookie 解析安全可靠，但需注意 max-age 逻辑、secure/httponly 解析、多值覆盖；request.cookies() 返回空切片常见于非法格式、samesite 拦截、path/domain 匹配失败、未解码 url 编码值。
Go 标准库的 http.Cookie 解析是安全且可靠的，但直接用 http.ParseCookie 或手动拆解 Cookie 头容易漏掉关键细节——比如未设置 Max-Age 时的过期逻辑、Secure/HttpOnly 的布尔值解析、以及多值同名 Cookie 的覆盖行为。
为什么 http.Request.Cookies() 有时返回空切片？
不是所有请求都带 Cookie 头，也不是所有 Cookie 都能被自动解析。常见原因包括：
-
Cookie请求头格式非法（例如含未编码的空格、分号或等号在值中未转义）；http.Request.Cookies()会静默跳过整个头，不报错也不提示 - 服务端设置了
SameSite=Strict或SameSite=Lax，而当前请求跨站触发了浏览器拦截，根本不会发送头 - 客户端使用了
document.cookie手动写入但未设path或domain，导致匹配失败（Go 解析时只按 RFC 6265 规则做字符串匹配，不模拟浏览器路径匹配逻辑） - Cookie 值含 URL 编码字符（如
%3D），但没被url.QueryUnescape解码——http.Request.Cookies()不自动解码，需手动处理Cookie.Value
http.ParseCookie 和 http.SetCookie 的参数陷阱
这两个函数看似对称，但行为不对称：前者只解析单个 Cookie 字符串（如 "name=value; Path=/; HttpOnly"），后者生成的是完整响应头字段（Set-Cookie: name=value; Path=/; HttpOnly）。常见误用：
- 传给
http.ParseCookie的字符串不能带Cookie:前缀，也不能是多个 Cookie 拼接（如"a=1; b=2"），否则返回nil+ 错误 -
http.SetCookie要求*http.Cookie的Name和Value非空，否则 panic；Value中若含逗号、分号、空格，必须先url.PathEscape（不是QueryEscape）再赋值，否则浏览器可能截断 -
MaxAge设为0表示“不设 Max-Age 属性”，而非“立即过期”；设为负数才表示删除（等效于Expires设为过去时间）
如何安全读取和验证带签名的 Cookie？
标准库不提供签名/加密功能，必须借助第三方包（如 gorilla/securecookie）或自己用 crypto/hmac。关键点：
- 不要自己拼接
hmac.Sum([]byte(cookieValue + secret))——这易受长度扩展攻击；应使用hmac.New+Write+Sum标准流程 - 签名 Cookie 应分离「值」和「签名」，推荐格式：
value.base64-encoded-signature，解析时先strings.SplitN(raw, ".", 2)，再验证签名 - 验证失败时，务必返回空值或默认值，**不要**返回原始未签名值（防止篡改后降级使用）
- 若用
gorilla/securecookie，注意其默认使用SHA256+AES，密钥长度必须严格满足：加密密钥 32 字节、哈希密钥 32 字节；少一字节就会 panic
Cookie 的解析逻辑藏在浏览器和 Go 的双重规则里：RFC 6265 定义语法，Go 实现解析器，但浏览器决定是否发送。最常被忽略的是——Path 和 Domain 匹配由客户端完成，服务端拿到的只是最终筛选后的结果，无法回溯原始 Cookie 列表。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
