多个团队共同维护一个网站时，上线前最常出现的问题不是某个功能完全不能用，而是各团队各自完成了自己负责的部分，但拼在一起后体验出现了断裂。比如一个团队负责内容，另一个团队负责前端样式，第三个团队负责后台接口，每边单独看都没问题，合在一起却出现错位、信息矛盾或流程中断。上线前的基础体验核对，核心就是把这些接缝处的情况拉出来看一遍。
第一类值得核对的是页面能否正常到达和正常显示。具体包括：主要入口链接是否都能打开、图片是否加载出来、在不同屏幕宽度下排版是否出现明显溢出或遮挡。跨团队场景下容易忽略的是，某个团队替换了资源路径或调整了页面结构，但没有通知依赖这些路径的其他团队。建议上线前把核心页面逐一打开浏览一遍，而不是只看自己负责的那几个页面。
第二类是信息口径的一致性。导航栏的名称、页面标题、联系方式、服务说明这些内容，如果分属不同团队维护，很容易出现同一个服务在不同页面叫法不同，或者某处更新了而另一处还是旧文案。核对时可以把用户从进入网站到完成主要操作的路径走一遍，沿途看信息是否前后对得上。
第三类是异常和边界情况的处理。表单提交后有没有明确的反馈提示、输入错误时是否有可理解的说明、访问不存在的页面时是否有引导。这些往往不属于任何一个团队的"核心职责"，容易落在缝隙里。上线前可以故意输入一些错误内容、访问几个不存在的地址，看看网站给出的反应是否对用户友好。
落地时比较实际的做法是列一份简短的核对清单，每项注明由谁确认、确认的标准是什么、确认后记录结果。清单不需要很长，覆盖上面提到的几类就够用。关键是在上线前留出时间让各团队一起过一遍，而不是各自确认完就认为可以发布。如果核对中发现了问题，记录清楚再决定是修复后上线还是带着已知问题先上线并标注后续处理计划。