fix(token-stats): 修复 token 统计异常和响应时间为 0 的 Bug

[jsrcode]

动机

透明代理的 token 统计功能存在两个关键 bug:

1. 响应时间始终为 0: 所有请求记录的 response_time_ms 字段都是 0
2. output_tokens 统计错误: 大部分记录的 output_tokens 为 1-5(message_start 的初始值),而非实际的最终值(数百)

根本原因是 SSE 流完成检测机制使用了固定延迟(2秒) + 轮询稳定性检测,导致统计任务在流真正结束前就执行,错过了包含最终 token 数据的 message_delta 事件。

主要改动点

1. 修复响应时间统计 (commit 4eb7899)

问题:

• RequestLogContext 创建新 Instant::now() 而非使用传入的 response_time_ms
• elapsed_ms() 返回从上下文创建到统计的时间(约 0ms),而非真实响应时间

修复:

• 将 RequestLogContext.start_time: Instant 改为 response_time_ms: Option<i64>
• 在 proxy_instance.rs 计算响应时间后直接传入上下文
• 所有日志记录调用使用 context.response_time_ms

影响文件:

• src-tauri/src/services/proxy/log_recorder/context.rs
• src-tauri/src/services/proxy/log_recorder/recorder.rs
• src-tauri/src/services/proxy/headers/claude_processor.rs

2. 添加详细调试日志 (commit f652cfd)

为排查 output_tokens 异常问题添加完整的日志链路:

extractor.rs:

• 每个 SSE 事件的解析日志(event_type)
• message_delta 检测和提取成功日志
• Token 值提取日志(output_tokens, cache_creation, cache_read)

manager.rs:

• SSE chunks 数量和解析开始日志
• 每个 chunk 的事件类型和预览
• message_start/delta 的 token 值详细日志
• 合并前后的对比日志(has_delta, start_output, delta_output)
• 最终 token 信息日志

影响文件:

• src-tauri/src/services/token_stats/extractor.rs (+15 行日志)
• src-tauri/src/services/token_stats/manager.rs (+27 行日志)

3. 使用流完成信号替代轮询检测 (commit 3d2bb93)

问题:

// ❌ 旧方案: 固定延迟 + 轮询稳定性检测
tokio::time::sleep(Duration::from_millis(500)).await;
for _ in 0..20 {
    let current_count = sse_chunks.lock().map(|g| g.len()).unwrap_or(0);
    if current_count == prev_count {
        stable_count += 1;
        if stable_count >= 3 { break; }
    }
    tokio::time::sleep(Duration::from_millis(500)).await;
}

• 本质是"预测"流何时结束,不可靠
• message_delta 在流的最后才发送,过早统计会错过
• 违反用户明确要求:"不使用延迟、预测"

修复:

// ✅ 新方案: 事件驱动的流完成检测
let (stream_end_tx, stream_end_rx) = tokio::sync::oneshot::channel::<()>();

let mapped_stream = stream
    .map(/* 收集 chunks */)
    // 在流的最后一个元素之后插入完成信号
    .chain(futures_util::stream::once(async move {
        let _ = stream_end_tx.send(());
        Err(/* 结束标记 */)
    }))
    .filter(/* 过滤结束标记 */);

tokio::spawn(async move {
    // 真正等待流完全消费(无超时,无轮询)
    stream_end_rx.await
    // ...统计处理
});

架构优势:

• 使用 tokio::sync::oneshot 通道 + futures_util::stream::chain()
• 在流的最后一个元素之后自动发送完成信号
• 统计任务通过 await 真正等待流结束,无任何预测逻辑
• 删除所有轮询和固定延迟代码(净减少 151 行)

影响文件:

• src-tauri/src/services/proxy/proxy_instance.rs (+67 行)

测试情况

功能验证

修复前日志:

合并前: start vs delta has_delta=false start_output=1
合并后: 最终 Token 信息 final_output=1

修复后日志:

SSE 流已完全消费完毕,发送完成信号
✓ 收到 SSE 流完成信号,流已完全消费
合并前: start vs delta has_delta=true start_output=8 delta_output=24
合并后: 最终 Token 信息 final_output=24

代码质量

• ✅ 所有检查通过 (ESLint + Clippy + Prettier + rustfmt)
• ✅ 编译通过 (v1.5.4)
• ✅ 无新增警告

数据库验证建议

-- 修复前: 大部分 output_tokens 为 1-5, response_time_ms 为 0
-- 修复后: 应该看到正确的 token 统计和响应时间
SELECT session_id, output_tokens, response_time_ms, created_at 
FROM request_logs 
ORDER BY created_at DESC 
LIMIT 10;

风险评估

低风险

1. 流完成检测机制变更:

   • 从轮询改为事件驱动,架构更清晰可靠
   • 使用标准库 futures_util (无新依赖)
   • 通过 .filter() 移除标记,不影响下游

2. 上下文字段变更:

   • RequestLogContext 简化为接收预计算的 response_time_ms
   • 调用方已全部更新,类型安全

3. 日志增强:

   • 仅新增 DEBUG/INFO 级别日志,不影响性能
   • 生产环境默认日志级别可过滤

测试覆盖

• 现有单元测试全部通过(无新增测试)
• 通过实际代理请求验证 token 统计正确性
• 日志输出证明 message_delta 成功捕获

向后兼容

• ✅ 数据库 schema 无变更
• ✅ 命令层接口无变更
• ✅ 前端调用无变更

潜在影响

可能影响: 历史统计数据对比

• 修复前的记录: output_tokens 偏低,response_time_ms 为 0
• 修复后的记录: 数据准确
• 建议: 可在数据库迁移中添加标记字段区分修复前后

关联 Issue

无 (内部发现的 bug)

变更总结

指标	值
文件修改	6 个
代码净增	+196 -83 (净增 113 行)
提交数量	3 个
检查状态	✅ 全部通过
功能影响	Token 统计准确性 + 响应时间记录

[github-actions]

本评论会随各平台任务完成自动更新：
如首轮 npm run check 失败，请在本地执行 npm run check:fix → npm run check 并提交修复 commit。
如 fix 仍失败，请在本地排查并确保 npm run check 通过后再提交。
跨平台差异若无法复现，请复制日志交给 AI 获取排查建议。

平台	结果	明细	日志包	运行链接
ubuntu-22.04	✅ 直接通过	check=success / fix=skipped / recheck=skipped	pr-check-ubuntu-22.04	日志
windows-latest	✅ 直接通过	check=success / fix=skipped / recheck=skipped	pr-check-windows-latest	日志
macos-14 (arm64)	✅ 直接通过	check=success / fix=skipped / recheck=skipped	pr-check-macos-arm64	日志
macos-15 (x64)	✅ 直接通过	check=success / fix=skipped / recheck=skipped	pr-check-macos-x64	日志

---

This comment auto-updates as each platform finishes:
If the first npm run check fails, run locally: npm run check:fix → npm run check and commit the fix.
If fix still fails, investigate locally and ensure npm run check passes before committing.
If cross-platform issues can't be reproduced, copy logs to an AI for hints.

Platform	Status	Detail	Artifact	Run
ubuntu-22.04	✅ Passed	check=success / fix=skipped / recheck=skipped	pr-check-ubuntu-22.04	日志
windows-latest	✅ Passed	check=success / fix=skipped / recheck=skipped	pr-check-windows-latest	日志
macos-14 (arm64)	✅ Passed	check=success / fix=skipped / recheck=skipped	pr-check-macos-arm64	日志
macos-15 (x64)	✅ Passed	check=success / fix=skipped / recheck=skipped	pr-check-macos-x64	日志