关掉页面后仍在计费：用四个时间点追查流式响应

用户看到的停止，不是计费链路的终点

访客在第8秒关闭标签页，界面会立即消失；但请求可能已经由WordPress送出，供应商也可能正在生成第一个或后续令牌。浏览器的中止信号能否穿过反向代理、PHP进程和供应商接口，需要逐层验证，不能根据前端表现推断。

先挑选一条争议请求，不要从整月账单倒推。理想样本具有浏览器开始时间、前端中止时间、WordPress请求编号、供应商请求编号和最终用量。缺少编号时可用UTC时间、模型和输出规模缩小匹配范围，但结论中必须标记匹配的不确定性。

对齐浏览器、WordPress、传输层和供应商四个时钟

四个时间源必须先校准。浏览器记录发起与AbortController触发时刻；WordPress记录收到请求、发出上游调用及本地函数返回；传输层记录客户端断开、上游连接状态与字节结束；供应商记录接收、完成、取消结果和计量用量。所有记录换算为UTC，并保留各系统可能存在的时钟偏差。

若样本显示0秒发起、8秒浏览器中止、9秒WordPress感知断开、41秒供应商完成，已能证明费用并非在界面消失时停止。还需要确认9秒后PHP是否继续等待、代理是否缓冲响应，以及供应商是否提供并成功执行了取消操作。

先识别断点，再选择控制手段

如果WordPress从未收到中止，先检查前端请求、代理缓冲和服务器运行方式；如果WordPress收到中止但没有终止上游调用，修复取消传递；如果供应商收到取消仍继续计量，则应按该供应商的正式语义处理，而不能假定所有接口都能即时停止。

无法可靠取消时，把风险改造成可计算上限

取消不是唯一控制。可以限制最大输出令牌、设置服务器端截止时间、禁止断线后自动重试，或将长任务改为明确的后台工作并向用户说明。选择标准是最坏费用、回答完整度和实现可靠性，而不是哪个方案在一次演示里最快。

为每个候选方案执行至少10次受控中止，分别在收到首字节前、流式输出中段和接近完成时断开。记录成功取消比例、断开后继续时间、最终计量令牌和用户可见错误；只有重复结果稳定，才能写入生产规则。

流式请求中止时间线的验收标准

时间线应能回答三个问题：费用从何时起不可避免，哪一层拥有停止能力，以及停止失败时的最大暴露是多少。若只能证明浏览器已关闭，却无法关联供应商用量，这份材料仍是线索，不是根因报告。

不要把正常完成误报成恶意调用

这类事件的来源通常是取消机制没有贯通，而非Bot流量。修复重点应放在请求从开始到结束的处理流程和输出上限；把Human/Bot/Unknown分类当作替代证据，会掩盖真正的传输问题，也可能误伤正常访客。

为费用上限增加第二道保护

完成重建后，把断线样本、供应商取消能力和最大输出设置纳入变更记录。若单次输出上限不足以覆盖全天累计风险，再评估Pro所提供的保护能力，而不是把升级方案当作取消传播的替代品。

把“关掉页面后仍在计费：用四个时间点追查流式响应”的流式请求中止时间线用于第一次真实安装。免费下载 AI Cost Circuit Breaker，先从 Monitoring 开始，验证预期信号和回退方式后再启用强制控制。