用户已经登录，账户菜单仍显示访客名称，迷你购物车也可能停留在登录前状态。整页 HTML 往往来自 FPC，客户信息由 customer-data 在浏览器端加载；问题通常是 section 未失效、版本 Cookie 未更新或自定义代码缓存了错误数据。

先固定复现条件和影响范围

在无痕窗口记录登录请求、customer/section/load 响应、private_content_version Cookie 和 Local Storage 中 mage-cache-storage、mage-cache-storage-section-invalidation。比较完整页面登录与 AJAX 登录两条路径。

grep -R --line-number 'sections.xml' app/code vendor 2>/dev/null
grep -R --line-number 'SectionSourceInterface' app/code 2>/dev/null
php bin/magento cache:clean config full_page
curl -sS -D - 'https://shop.example.com/customer/section/load/?sections=customer,cart' -o /tmp/sections.json

根据证据分支定位

section/load 已返回正确客户而页面仍旧，检查 Knockout 绑定和 JS 错误；响应本身还是访客，检查请求 Cookie、Session 与 SectionSource；登录后根本未请求 section/load，则检查 sections.xml 的 action 配置与自定义 AJAX 登录是否触发 invalidate/reload。

修复时保留回滚路径

为改变客户状态的 action 精确配置需要失效的 section，并在自定义前端流程成功后调用官方 customer-data invalidate/reload。不要把 customer、cart 等私有 section 放进公共 CDN 缓存，也不要靠每次清空所有 Local Storage 掩盖缺失的失效规则。

上线验收

访客、客户 A、客户 B 依次登录和注销，页头、购物车和收藏夹不得串号；测试 FPC HIT、浏览器后退和两个标签页，同一账户状态应在合理时间内同步。

生产环境操作前的检查

处理“Magento 2 登录后 customer-data 仍显示访客信息”前，先记录 Magento 版本、部署模式、问题 Store View、复现时间和最近一次发布。所有 SQL 默认先执行 SELECT；任何写操作、目录清理或配置切换都应确认影响范围、保留备份并准备回滚。多节点环境要核对各节点代码版本、app/etc/env.php 配置摘要与流量分布。

php bin/magento --version
php bin/magento deploy:mode:show
php bin/magento maintenance:status
php bin/magento indexer:status
php bin/magento cache:status

命令应由 Magento 文件所有者在项目根目录执行。不要在生产高峰同时运行全量索引、静态部署和数据修复；涉及客户、支付、税费或订单的改动，先在脱敏数据副本验证。

建立可比较的排查记录

每次实验只改变一个变量，记录操作前值、命令、开始与结束时间、结果和回滚方式。准备一个正常对象与一个异常对象对照；若旧对象恢复而新对象仍能复现，说明根因尚未消除。

检查层需要保存的证据通过标准
入口层 URL、状态码、请求 ID、节点 路由和协议一致
应用层 异常堆栈、模块、作用域 无新异常且可重复
数据层 主键、时间、关联行数 关系完整且无重复副作用
业务层 正常、失败、重试路径 最终结果一致

修复后的观察窗口

上线后至少观察一轮 Cron、队列和索引周期，并在两台节点、无痕浏览器和目标 Store View 重复验证。临时调试日志必须脱敏，确认错误率、响应时间和数据量稳定后及时关闭。