Revel 中 Cookie 分为 Session 与自定义两类：Session Cookie 安全属性由 app.conf 统一配置且不可手动覆盖；自定义 Cookie 必须通过 c.Response.Cookies 显式添加，安全参数需在 *http.Cookie 构造时设置，删除时需严格匹配 Name/Path/Domain 并设 MaxAge=-1。
Revel 的 Cookie 设置必须通过 c.Response.Cookies 显式添加，不能直接操作 http.SetCookie；安全属性（如 Secure、HttpOnly、SameSite）需在构造 http.Cookie 时传入，且 Session 和普通 Cookie 的控制方式完全不同。
Session Cookie 的安全属性由框架自动控制，无法手动覆盖
Revel 的 Session 是基于加密签名的 Cookie 实现，其生命周期、域名、路径、HttpOnly 和 Secure 属性均由框架在 SessionFilter 中统一配置，不响应你在代码里对 c.Session 的任何“属性设置”。
-
c.Session只是一个map[string]string，你只能存键值对，不能设过期时间或安全标志 - 真正控制 Session Cookie 安全性的配置项是
app.conf中的：session.cookie.secure、session.cookie.httponly、session.cookie.samesite - 若部署在 HTTPS 前置代理后（如 Nginx），必须设置
session.cookie.secure = true且确保X-Forwarded-Proto正确传递，否则Secure标志不会生效
如何手动设置自定义 Cookie（非 Session）
需要绕过 Session 机制、写入独立 Cookie 时，必须使用 c.Response.Cookies 切片并调用 http.SetCookie —— 这是唯一有效途径。
- 不能用
http.SetCookie(c.Response.Out, ...)：因为c.Response.Out是http.ResponseWriter，而 Revel 已接管写入流程，直接调用会冲突或被忽略 - 正确做法是构造
*http.Cookie后追加到c.Response.Cookies：
cookie := &http.Cookie{
Name: "theme",
Value: "dark",
Path: "/",
MaxAge: 60 * 60 * 24 * 7, // 7 days
HttpOnly: true,
Secure: revel.Config.BoolDefault("session.cookie.secure", false),
SameSite: http.SameSiteLaxMode,
}
c.Response.Cookies = append(c.Response.Cookies, cookie)
-
MaxAge推荐显式设置，避免依赖Expires（部分客户端处理不一致） -
SameSite值必须用http.SameSiteXXXMode常量，字符串如"Lax"无效 - 若要删除 Cookie，设
MaxAge: -1并确保Name、Path、Domain与原 Cookie 完全一致
常见错误：混用 Session 和普通 Cookie 导致安全策略失效
开发者常误以为给 c.Session["token"] 存一个 JWT 就等同于设置了带 HttpOnly 的认证 Cookie —— 实际上它仍走 Session 加密流程，且无法控制 SameSite 或精细过期逻辑。
- 敏感令牌（如 access token）不应塞进
c.Session，应单独设为HttpOnly + Secure + SameSite=Strict的独立 Cookie - Session 适合存轻量、非敏感、需签名防篡改的数据（如用户 ID、语言偏好）；重权限凭证必须隔离管理
- Revel 默认不限制 Cookie 大小，但浏览器限制约 4KB；
c.Session膨胀后可能触发截断，导致后续请求解析失败
真正关键的不是“怎么写”，而是分清哪些该走 Session 流程、哪些必须走原生 Cookie 控制——后者才能精确操控每个安全位。很多线上 XSS 或 CSRF 问题，根源都在这里模糊了边界。
