cookie读取用request.cookies（flask）或request.cookies（django），写入必须用response.set_cookie()；session依赖cookie存session_id，真实数据存服务端，密钥不一致、路径/域名/samesite配置错误等均会导致“有cookie却无session”。

request对象里怎么读写Cookie

HTTP协议本身无状态，Cookie是服务端通过响应头塞给浏览器、再由浏览器在后续请求中自动带回的键值对。读写都在request和response对象上，但注意：request只负责“读”，不负责“写”——写必须用response。

常见错误现象：request.cookies.get("user_id")返回None，但明明前端发了；或者反复调用response.set_cookie()却没生效。

• 读取时用request.cookies（Flask）或request.COOKIES（Django），它是个类字典对象，直接.get()最安全
• 写入必须调用response.set_cookie()，且需在return response前执行；不能靠修改request来“写”
• max_age和expires别同时设，后者是绝对时间戳，容易因服务器/客户端时钟不同步失效
• 敏感信息（如token）务必加httponly=True和secure=True（HTTPS环境），否则JS可读、明文传输

Session数据存在哪？request.session是啥

session不是HTTP标准字段，而是框架封装的会话抽象层。底层仍依赖Cookie（存session_id），但真实数据存在服务端——文件、数据库、Redis等后端可配。所以request.session本质是带自动加载/保存逻辑的字典代理。

使用场景：用户登录态维持、临时表单数据暂存、防重复提交的csrf_token绑定。

• Django默认用数据库存session，需运行python manage.py migrate建表；Flask默认用签名Cookie，数据全在客户端加密存储，别放敏感内容
• request.session.modified = True在某些框架里是必需的——比如你只改了嵌套字典的值，框架可能检测不到变更，导致不持久化
• 调用request.session.flush()会删服务端记录+清客户端sessionid Cookie；而request.session.clear()只清数据，ID还在
• 跨域请求时，credentials: 'include'和response的Access-Control-Allow-Origin不能为*，否则浏览器拒绝发送Cookie

为什么有时候Cookie有、Session却取不到

典型现象：浏览器开发者工具看到Cookie里有sessionid，但request.session.get("user")始终为空。这不是代码写错了，而是会话生命周期断在了某个环节。

根本原因：服务端找不到对应session_id指向的数据，或校验失败。

• 密钥不一致：Flask的SECRET_KEY或Django的SECRET_KEY重启后变了，旧Cookie解签失败，直接丢弃
• 过期时间错配：SESSION_COOKIE_AGE（框架级）和set_cookie(max_age)（底层）冲突，后者优先级更高，可能提前失效
• 路径/域名不匹配：设置domain=".example.com"但请求来自api.example.com，浏览器不会发；或path="/admin"但请求是/api/login，也送不出
• SameSite策略拦截：Chrome 80+默认SameSite=Lax，跳转或表单POST跨站时，Cookie不携带——调试时注意看Network面板的Request Headers里有没有Cookie字段

并发请求下Cookie和Session怎么不串？

多个标签页、AJAX轮询、微前端共存时，看似共享Cookie，但session数据不会互相污染——因为每个请求的session_id是独立解析、独立加载的。真正要小心的是手动共享request.session引用或全局缓存。

性能影响：如果用文件或数据库存session，高并发下I/O或锁竞争会拖慢；Redis是更常见的生产选择。

• 不要把request.session传给异步任务（如Celery）——任务执行时request已销毁，session对象失效
• 避免在中间件或装饰器里直接赋值request.session["data"] = big_dict，大对象序列化开销明显；优先用request.session.setdefault()做轻量初始化
• Redis后端要注意SESSION_SAVE_EVERY_REQUEST开关：关则只在修改时保存（省IO），开则每次请求都续期（防过期），但增加一次网络往返
• 测试时容易忽略时区：datetime对象存进session再取出，可能因序列化丢失tzinfo，建议统一转为时间戳或字符串

会话机制看着简单，但Cookie路径、SameSite、密钥轮换、后端存储选型这些点，任何一个配错都会让“明明写了却读不到”变成常态。线上出问题，先盯死Network里的Request Headers和Response Headers，比翻代码快得多。