Lighthouse性能分数变绿，而PageSpeed Insights上方的真实用户体验仍未通过，两者不一定矛盾。前者反映一次受控环境下的页面运行，后者来自一段时间内符合采集条件的真实访问。先核对URL或来源级别、移动或桌面、采集窗口和页面状态，再判断修改有没有生效。拿今天的一次测试去推翻过去一段时间的用户记录，会把排障方向带偏。
先确认正在比较哪一块数据
PageSpeed Insights把两类数据放在同一页，容易让人误以为它们必须同时变化。Google的PSI说明明确区分：实验室数据便于在受控条件下定位问题，但未必覆盖现实瓶颈；现场数据反映真实体验，却没有完整的调试细节。性能总分也不能直接当成LCP、INP或CLS的值。
打开报告，先把数据区域的名称、测试地址、设备类别和日期记下来。查看真实用户区展示的是当前URL，还是整个来源。来源通常由协议、域名与端口共同确定，不等于这个产品页，也不等于把所有子域名合在一起。某条URL样本不够时，PSI可能转而显示来源级数据；若来源也不足，则不能显示相应用户体验数据。
原创场景插画：一次固定环境实验与分散的真实使用场景。图中没有性能分数或客户统计。
不要把“没有足够数据”抄成“通过”。新发布的外贸产品页访问有限，缺少CrUX记录很正常；此时可以做本地诊断，也可以在隐私与权限允许的前提下补充自己的真实用户监测，但不能用几次手工打开替代用户分布。
修改已经上线，为什么上面的数字还没动
PSI的真实用户数据覆盖此前28天的采集窗口，并按日更新。修复发布后，新旧版本的访问会暂时共存于窗口内。要记录部署时间和实际资源版本，持续观察窗口变化，而不是期待刷新报告立即全部变绿。28天是统计窗口，不是“修完必须等满28天才可能变化”的固定等待期。
同时查部署是否真的覆盖目标用户。浏览器缓存、CDN旧HTML、不同国家节点或语言模板，都可能让部分访问继续使用旧版本。一个假设例子是：英文产品模板修了首图，但文章模板和其他语言仍旧；来源级LCP没有明显改变，并不能单独证明英文模板修复失败。遇到语言内容不一致，应另外检查多语言HTML缓存串页，不要继续反复压缩图片。
PSI在有足够相应数据时使用第75百分位评估体验。它不是把全部访问算个平均值，也不代表每位访客都体验良好。验收时写清指标对应的对象和分布口径，不能把一个群体的结果套给另一个页面。
把实验室复测做成可比较的记录
- 固定页面及版本。记录最终跳转后的URL、构建标识或资源地址，避免一轮测首页、一轮测产品页。
- 固定运行环境。保持设备模拟、网络与CPU限速、浏览器版本和测试地点一致；不要同时开多个重型审计争抢本机资源。
- 固定访问状态。分别定义首次访问、已同意Cookie、已拒绝、回访有缓存，不能把拒绝全部脚本的一轮与接受全部脚本的一轮当作同条件。
- 保留多轮原始结果。可以少量串行重复，记录中位数及波动范围，异常运行附说明，不只挑最高分截图。
- 比较指标和诊断。确认慢的是资源发现、主线程还是布局变化，别仅追逐总分的变化。
冷缓存与热缓存都有价值，但要分开。测试工具是否清除Cookie、存储和网络缓存，要按实际运行方式检查，不同入口未必一致。一个已登录、关闭同意横幅的开发浏览器，通常不能代表首次进入公开网站的采购访客。
“实验室好、用户差”要怎样继续查
先检查实验是否漏了真实操作。只跑导航加载，不会充分覆盖选规格、填写询盘、打开客服或接受同意后的行为。若用户抱怨提交按钮停顿，应录制那次交互，按表单INP与主线程排查拆开延迟，而不是要求导航测试再加几分。普通导航Lighthouse中的TBT可提供阻塞线索，但不是页面全生命周期的INP。
再看实际访问分组。目标市场距离、终端能力、网络、访问的模板和版本不同，都可能产生实验未覆盖的慢体验。自己的监测有条件时按这些维度找集中问题，避免上报表单内容等个人信息；没有这些记录，就把原因列作待验证假设，不编造“海外客户手机较差”的结论。
如果没有自己的监测权限，仍可请维护者提供去标识化的分组结果，例如模板、设备类别和发布版本。先确定能够取得哪些证据，再决定是否升级监测；不需要为排查一张图片就要求完整客户行为明细或最高级账号权限。
一份能执行的结论应留下什么
性能工单至少留下：报告数据区域、目标URL或来源、设备类别、采集周期、复测配置、原始报告和下一步验证动作。例如“产品模板首图发现已提前，固定条件实验支持该判断；真实用户窗口仍混合旧版本，继续观察移动端LCP”，比“网站已全面达标”更准确。本文没有执行客户Lighthouse审计，也没有客户提分数据。
如果需要把性能问题纳入网站技术工作，可参考光算谷歌SEO服务中的网站代码优化与移动端适配方向；具体页面、测试环境、开发配合和验收范围按项目确定。分数可以提示问题，报告最终要回答的是哪类用户在哪一步仍受影响。