金丝雀监控 — 部署后监控
使用时机
- 部署到生产或预发布环境后
- 合并高风险PR后
- 想要验证修复是否确实生效时
- 在发布窗口期间持续监控
- 依赖升级后
工作原理
监控已部署的URL是否有回归。循环运行，直到被停止或监控窗口到期。
监控内容
1. HTTP 状态 — 页面是否返回200？
2. 控制台错误 — 是否出现了之前没有的新错误？
3. 网络故障 — 失败的API调用、5xx响应？
4. 性能 — LCP/CLS/INP与基线相比是否有回归？
5. 内容 — 关键元素是否消失？（h1、导航、页脚、CTA）
6. API 健康 — 关键端点是否在SLA内响应？
7. 静态资源 — JS、CSS、图像和字体请求是否返回2xx/3xx并带有预期的内容类型？
8. SSE 流 — 事件流端点是否成功连接并接收到初始事件或心跳？
监控模式
快速检查（默认）：单次通过，报告结果
/canary-watch https://myapp.com
持续监控：每隔N分钟检查一次，持续M小时
/canary-watch https://myapp.com --interval 5m --duration 2h
差异模式：比较预发布与生产环境
/canary-watch --compare https://staging.myapp.com https://myapp.com
警报阈值
critical: # 立即警报
- HTTP状态 != 200
- 控制台错误计数 > 5（仅新错误）
- LCP > 4s
- API端点返回5xx
- 静态资源返回4xx/5xx
- SSE端点无法连接或在首次心跳前断开
warning: # 在报告中标记
- LCP比基线增加超过500ms
- CLS > 0.1
- 新的控制台警告
- 响应时间超过基线2倍
- 静态资源内容类型意外改变
- SSE心跳延迟超过基线2倍
info: # 仅记录日志
- 微小的性能差异
- 新的网络请求（添加了第三方脚本？）
通知方式
当触达关键阈值时：
- 桌面通知（macOS/Linux）
- 可选：Slack/Discord webhook
- 记录到
~/.claude/canary-watch.log
输出
## 金丝雀报告 — myapp.com — 2026-03-23 03:15 PST
### 状态：健康 ✓
| 检查项 | 结果 | 基线 | 差异 |
|--------|------|------|------|
| HTTP | 200 ✓ | 200 | — |
| 控制台错误 | 0 ✓ | 0 | — |
| LCP | 1.8s ✓ | 1.6s | +200ms |
| CLS | 0.01 ✓ | 0.01 | — |
| API /health | 145ms ✓ | 120ms | +25ms |
| 静态资源 | 42/42 ✓ | 42/42 | — |
| SSE /events | 已连接 ✓ | 已连接 | +80ms 心跳 |
### 未检测到回归。部署干净。
集成
配合使用：
/browser-qa用于部署前验证- 钩子：作为
git push上的 PostToolUse 钩子添加，在部署后自动检查 - CI：在部署步骤后的 GitHub Actions 中运行