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()会删服务端记录+清客户端sessionidCookie；而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，比翻代码快得多。
