代码发布完成，页面没有报错，但所有登录客户都回到未登录状态。很多团队把它当成“清缓存的正常现象”，其实 Magento 页面缓存与客户 Session 是不同数据。正常的静态资源发布、DI 编译和页面缓存刷新，不应该必然删除所有会话。

确认 Session 存在哪里

查看 app/etc/env.php 的 session 配置：文件、Redis 或其他存储。多 Web 节点若用本地文件且没有粘性会话，客户请求切到另一节点就像被登出；蓝绿发布切换节点后现象会更明显。

Redis 环境重点比较发布前后的 host、port、database、prefix 和连接参数。部署模板如果每次生成随机前缀，旧 Session 仍在 Redis 中，但新代码找不到。不要为了排查在聊天或日志中暴露 Redis 密码。

发布脚本是否误清 Session

grep -R 'cache:flush|FLUSHDB|session' deploy/ .github/ 2>/dev/null
redis-cli -n 2 DBSIZE

路径和 Redis DB 仅为示例。cache:flush 可能清理共享 Redis 实例中的其他数据，若 cache 与 session 使用同一 DB 或错误前缀，影响更大。发布流程应使用精确的 Magento cache clean，并把 session 独立隔离。

Cookie 是否在发布时改变

比较发布前后的 Set-Cookie：域名、Path、Secure、HttpOnly、SameSite 和过期时间。Base URL、HTTPS offloader 或 Cookie Domain 被配置管理覆盖后，浏览器可能不再发送旧 cookie。用浏览器 Network 看请求 Cookie，比只看 Application 面板更可靠。

加密密钥与节点配置必须一致

env.php 中的 crypt key 不应在每次部署重建。多节点 key 不一致会破坏依赖加密的数据，并可能表现为会话异常。部署包应保留环境专属密钥，通过安全配置注入；不能把新环境的 env.php 直接覆盖生产。

会话寿命和 GC

若不是所有客户同时退出，而是发布后活跃用户更容易失效，检查 session lifetime、Redis TTL、PHP gc_maxlifetime 与 Magento Cookie Lifetime。长时间维护模式导致 TTL 到期属于另一种情况。记录 session key 的 TTL 随请求是否刷新，能区分超时与主动删除。

修复验证

在发布前建立两个测试会话，记录脱敏后的 session 标识；执行与生产相同的蓝绿切换、缓存清理和流量迁移；发布后确认 cookie 仍发送、后端 key 仍存在、TTL 合理且客户保持登录。再分别测试购物车和后台管理员会话。目标不是永不让 Session 过期，而是代码发布不应成为无条件失效事件。若必须主动失效，应作为安全变更明确通知，而不是发布脚本的副作用。