网页应用日常巡检的检查顺序网页巡检不是每天打开首页看一眼也不是给 Lighthouse 分数做个截图。真正有用的巡检要从用户是否能完成关键动作开始再逐层定位页面、静态资源、接口、浏览器运行时和发布状态。顺序明确告警才会指向下一步该查什么而不是把值班人员淹没在一串控制台信息里。先选少量关键路径例如匿名访问首页、登录、提交表单、查看一条受权限保护的数据。每条路径应有明确的成功条件页面可用、关键元素出现、接口返回可预期的状态、敏感内容没有意外出现。不要把所有页面一次性塞进探测任务覆盖范围应随版本和故障历史调整并给每条路径设定负责人。从入口到浏览器逐层收集信号第一层检查入口可达性和发布版本。记录请求最终落到的版本、状态码、重定向和静态资源加载情况。部署后常见的资源问题不是“Chunk 一定失效”而是 HTML 引用与 CDN 缓存中的资源版本不一致、缓存规则错误或发布回滚不完整。探测应保存资源 URL、响应状态和版本标识方便与发布记录比对。第二层检查 API 的业务结果。一个 HTTP 200 不代表功能成功接口可能返回空数据、错误字段或过期会话。测试账号应具备最小权限凭据应由安全的密钥管理系统注入测试数据也要避免触及真实用户记录。巡检结束后应清理可清理的测试对象并对失败重试设置上限避免监控本身制造压力。第三层才是浏览器运行时。控制台错误、未处理的请求失败和渲染异常可以作为线索但不能单独等同于用户故障。Hydration 警告可能来自真实的服务端与客户端渲染差异也可能是第三方脚本或浏览器扩展造成需要关联页面版本、重现步骤和实际交互结果。内存数据在不同浏览器和自动化环境中的可获得性也不同单次堆大小不能证明内存泄漏更可靠的是在固定流程、固定版本下观察多轮运行的趋势。import { test, expect } from playwright/test; test(匿名用户可以查看产品页, async ({ page }) { const failures: string[] []; page.on(response, (response) { if (response.status() 500) failures.push(response.url()); }); await page.goto(process.env.CHECK_BASE_URL /products, { waitUntil: domcontentloaded, }); await expect(page.getByRole(heading, { name: 产品 })).toBeVisible(); await expect(page.getByTestId(product-list)).toBeVisible(); expect(failures).toEqual([]); });这个示例没有把networkidle作为统一成功条件。流式页面、长轮询、埋点和第三方资源可能让网络长期不空闲每条路径应等待与业务相关的元素或事件。若要测量用户体验指标也应在真实用户监测与受控合成测试中分别采集并说明设备、网络、缓存和采样条件。告警要保留上下文并控制噪声一次失败告警至少应包括测试路径、环境、版本、时间、截图或 trace 的保存位置、失败步骤和已脱敏的错误摘要。不要把完整 URL 参数、Cookie、授权头或用户输入转发到聊天群。相同发布版本在短时间内的重复失败可以聚合不同区域或不同网络条件的失败则应保留区分避免一个短暂 DNS 波动掩盖真实回归。巡检还要区分发布验证与日常可用性监测。发布验证关注新版本是否破坏了关键流程可以运行较慢、覆盖更广的浏览器用例日常监测更重视稳定、低侵入和快速告警。两者共用相同的脚本和数据时应明确频率、并发与运行权限避免测试账号相互干扰。最后定期回看告警哪些真正发现了故障哪些只是噪声哪些路径在架构变化后已经失效。把确认有效的检查留在清单中把无行动价值的指标移除或降级。巡检的价值不在于采集更多数据而在于让一次异常能被可靠地复现、定位和恢复。