正确设置需同时满足传输层和运行时条件：Secure 仅在 HTTPS 下生效，开发时用 r.TLS != nil 自动判断；HttpOnly 防 XSS 且无兼容问题；SameSite 必须显式设为 Lax 以平衡安全与可用性；优先用 MaxAge 控制过期。

Go 的 http.SetCookie 怎么正确开启 HttpOnly 和 Secure

直接设 HttpOnly: true 和 Secure: true 不够，必须同时满足传输层和运行时条件。否则浏览器会静默忽略 Secure，甚至拒收整个 Cookie。

• Secure: true 只在 HTTPS 下生效；本地开发用 http://localhost 时必须关掉它，否则 Cookie 写不进去（也看不到报错）
• HttpOnly: true 能防 XSS 读取，但不影响服务端写入逻辑，该设就设，没兼容性问题
• 别手动拼 Set-Cookie header 字符串——绕过 http.SetCookie 会丢失自动转义，容易被注入恶意值
• 示例写法：

  http.SetCookie(w, &http.Cookie{
      Name:     "session_id",
      Value:    "abc123",
      Path:     "/",
      HttpOnly: true,
      Secure:   r.TLS != nil, // 自动判断是否走 HTTPS
      SameSite: http.SameSiteLaxMode,
  })

为什么 SameSite 必须显式设置，且推荐 Lax

Go 1.11+ 默认不设 SameSite，而现代浏览器（Chrome 80+、Firefox 79+）会把未声明的 Cookie 当作 SameSite=Lax 处理，但行为不一致：有些老版本直接降级为 None，导致登录态丢失。

• SameSite=Strict 太激进，跨站链接会丢 Cookie，用户从微信点进来就登出
• SameSite=None 必须搭配 Secure: true，否则浏览器直接拒绝（报错：Cookie “X” has “SameSite=None” without “Secure”）
• SameSite=Lax 是平衡点：表单 POST、GET 导航保留 Cookie，防御 CSRF 同时不影响正常跳转
• 注意：Go 标准库用的是 http.SameSiteLaxMode 常量，不是字符串 "Lax"

Cookie 过期时间设 MaxAge 还是 Expires

优先用 MaxAge，它是秒数，由客户端相对计算，不受客户端时钟误差影响；Expires 是绝对时间，如果用户手机时间调快 2 小时，Cookie 立刻失效。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• MaxAge: 0 表示“会话级 Cookie”，关浏览器就删；负数会触发立即删除（浏览器收到后清空）
• Expires 如果设置了，Go 会自动忽略 MaxAge —— 二者别共存
• 别写 Expires: time.Now().Add(24 * time.Hour) 后忘了加 .UTC()，否则可能因时区解析失败被当成过去时间

测试 Secure 和 HttpOnly 是否生效的最快方法

别只看响应头，要验证浏览器实际行为。开 Chrome DevTools → Application → Cookies，看对应条目里 “Secure” 和 “HttpOnly” 列是否打钩。

立即学习“go语言免费学习笔记（深入）”；

• 如果没钩 Secure：检查是不是 HTTP 协议访问（哪怕 localhost）、反向代理有没有透传 X-Forwarded-Proto: https
• 如果没钩 HttpOnly：确认 http.SetCookie 里传的是 true，不是字符串 "true" 或未初始化零值
• 用 document.cookie 在控制台测：能读到说明 HttpOnly 没生效；读不到是正常的
• 换 HTTPS 地址再试一次，比改代码更快定位环境问题

关键点其实就两个：协议匹配（Secure 依赖 TLS）、SameSite 声明不可省。其他都是围绕它们的补丁。