Secure 标志仅强制浏览器通过 HTTPS 发送 cookie，不加密数据；若服务未启用 HTTPS 或反向代理未正确透传 X-Forwarded-Proto 头，cookie 会被静默丢弃。
Secure 标志本身不加密 cookie，只强制浏览器仅通过 HTTPS 发送 —— 如果你的服务没走 HTTPS，设了 Secure 也没用，cookie 会被直接丢弃。
为什么设置了 Secure 却还在 HTTP 下发出去？
常见原因是：后端实际运行在 HTTP（比如本地 http://localhost:3000），但代码里硬写了 Secure: true；或者反向代理（如 Nginx）没正确透传 TLS 信息，导致应用误判为非 HTTPS 环境。
- 浏览器严格遵守规范：只要当前页面是
http://，哪怕响应头带Set-Cookie: sid=abc; Secure，也会静默忽略该 cookie - Node.js 的
express-session默认不自动检测 HTTPS，需显式配置proxy: true并确保X-Forwarded-Proto头可信 - Python Flask 的
SESSION_COOKIE_SECURE = True在开发服务器（Werkzeug）下默认不生效，因为其内置服务器不支持 TLS
Express 中正确启用 Secure + HttpOnly 的写法
不能只写 res.cookie('token', 'xxx', { secure: true })，必须结合环境判断和代理设置：
- 生产环境必须走 HTTPS，且反向代理要加
proxy_set_header X-Forwarded-Proto $scheme; - Express 启动时需开启
app.set('trust proxy', 1)，否则req.secure永远为false - 推荐写法：
res.cookie('auth_token', token, { httpOnly: true, secure: process.env.NODE_ENV === 'production', sameSite: 'lax' });
Django 和 Flask 的 Secure 配置差异
Django 默认更保守：SESSION_COOKIE_SECURE 和 CSRF_COOKIE_SECURE 设为 True 后，若 request.is_secure() 返回 False（即没检测到 HTTPS），会直接拒绝写入 cookie —— 这比 Express 更早暴露配置问题。
- Flask 需手动设
app.config['SESSION_COOKIE_SECURE'] = True，但它不校验请求是否真走 HTTPS，容易“假 Secure” - Django 要求同时设
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')才能信任反代传来的协议头 - 两者都要求
SECURE_SSL_REDIRECT = True（Django）或app.enable('trust proxy')（Express）来配合，否则 Secure 可能失效
最常被忽略的一点：Secure 标志对 cookie 有效期、域名、路径等其他属性无影响，但它和 SameSite=None 组合时，必须同时设 Secure，否则现代浏览器（Chrome 80+）会直接拒收该 cookie —— 这个组合错误不会报错，只会让登录态莫名其妙丢失。
