先给判断

测试和 production build 通过，只能证明代码在构建环境里满足了部分静态契约。它不能证明正式 URL 可访问、资源路径正确、语言切换没有丢失、canonical 指向正确，或 390px 页面没有横向溢出。Playwright 的价值在于把这些真实浏览器行为纳入可重复的黑盒门，而不是把一堆 DOM 断言当作“用户体验通过”。

黑盒和白盒各自回答什么

单元测试适合问函数是否给出预期值；build 适合问路由和资源能否生成；Playwright 则从浏览器外部访问 URL，观察页面、网络和交互。三者不能互相替代。一个错误的 base path 可能让构建成功，却让 production 的 CSS、封面或 RSS 链接 404。

最小验收矩阵

对每个公开候选至少检查：

入口：根、中文首页、英文首页
文章：中文和英文
元数据：canonical、hreflang
结构：Article、BreadcrumbList
资源：sitemap、RSS、封面、正文图片
草稿路由：返回预期状态
390×844：无横向溢出
交互：语言、菜单、主题、目录

断言必须针对发布契约。比如“页面包含某个标题”不能替代“标题所在 URL 返回 200 且 canonical 自指”；“有一张图片”不能替代“声明的封面路径返回 200 且 naturalWidth 大于零”。

为什么要检查移动视口

响应式问题常常不在桌面截图里：长标题会溢出，目录浮层会覆盖正文，表格或代码块会产生水平滚动，触控目标会缩小到难以点击。使用真实 390×844 viewport，分别检查首屏、中段、底部和展开态，比一张 fullPage 图片更容易定位问题。

交互检查要带结果

点击语言切换后要确认目标页面的 lang、canonical 和文章标题都改变；主题按钮要确认可访问名称和视觉状态同步；目录项要确认 URL hash 和目标 heading 落点；搜索结果要确认链接进入公开文章而不是草稿。不要只记录“click succeeded”，还要记录点击后的可观测状态。

常见误区

用 dev server 代替 production preview；只检查 HTTP 状态而不检查正文和结构化数据；用旧截图证明新提交；把 Access 登录页误判成站点内容；只看 DOM 存在而不看计算样式和 viewport；以及为了通过测试把精确 route 集合改成宽松数量，都会让门禁失去意义。

可复现命令与边界

仓库应固定 Playwright 版本，先构建，再启动静态 preview，让测试访问生成产物。关键截图、trace 和 JSON 检查清单应绑定 commit SHA。Playwright 官方文档支持浏览器测试和报告能力；本文不声称任何未实际运行的截图、性能数字或线上结果。