【声明】本博客所有内容均为个人业余时间创作所述技术案例均来自公开开源项目如GithubApache基金会不涉及任何企业机密或未公开技术如有侵权请联系删除背景上篇 blog【Agent】【OpenCode】本地代理增强版分析超时机制实现综合之前所分析的setTimeout()给出了日志记录增强版 超时保护的实现与之前相比增强版的代理加入了setTimeout()超时机制防止代理请求长时间挂起超时时主动终止请求并记录错误日志避免内存泄漏或连接堆积接着继续分析了接收处理函数proxyRes.on(end, ...)相比于之前的.pipe()自动转发无法获取中间数据这里的代理需要缓存并手动拼接所有的 chunk 块在收到完整的 DashScope 响应后解析响应内容保存好结构化日志并向 OpenCode 客户端发送最终响应结束信号根据parsedBody.streamOpenCode 客户端发送的原始请求解析出 JS 对象判断是流式还是非流式响应并作相应处理下面继续分析OpenCode下面继续分析接收处理函数proxyRes.on(end, ...)之前 blog 分析了非流式响应的处理下面来看流式响应的处理logEntry.responseresponseBody;可以看到这里的处理就是直接存原始文本因为流式响应本质是多行文本SSE 格式无法直接转成单个 JSON 对象直接保存原始字符串就可以完整记录所有data事件举个流式日志的例子如下data:{id:1,choices:[{delta:{role:assistant}}]}data:{id:1,choices:[{delta:{content:Hello}}]}data:[DONE]接着是保存日志文件constlogFilepath.join(LOG_DIR,${timestamp}.json);fs.writeFile(logFile,JSON.stringify(logEntry,null,2),...);这里文件名用时间戳来确保唯一性比如1775952715073.json这里用的是 Unix 时间戳毫秒级表示从 1970 年 1 月 1 日 00:00:00 UTC被称为 Unix 纪元开始到当前时刻所经过的毫秒数所以 1775952715073 ≈ 2026-04-12 16:11:55 UTC选择 1970 年 1 月 1 日是计算机领域的历史约定源于 Unix 操作系统的设计1970s 年初Unix 开发者需要一个统一的时间起点所以大家选择了 1970-01-01T00:00:00Z 作为参考零点称为 Unix Epoch此后几乎所有操作系统编程语言CJavaPythonJavaScript 等都沿用了这一标准这是个全球统一时区无关的时间基准基于 UTCOK既然是基于某个历史时间的计数累积下面来分析下其数据溢出的可能性对于 JavaScriptJS 使用 IEEE 754 双精度浮点数64 位表示所有数字IEEE 754 双精度浮点数64 位的结构是1 位符号位11 位小数位52 位整数位根据 IEEE 754 规范有效整数精度由整数位 隐含最高位决定所以其安全整数范围是[− 2 53 1 -2^{53} 1−25312 53 − 1 2^{53} - 1253−1]按最大安全毫秒数换算成年份约为 285616 年也就是说 JavaScript 的毫秒时间戳要到公元 28 万年才会超出安全整数范围当前是公元 2026 年离整数溢出还早得很可以安全用这个时间戳做日志排序缓存键等任何用途OK本篇先到这里如有疑问欢迎评论区留言讨论祝各位功力大涨技术更上一层楼更多内容见下篇 blog【Agent】【OpenCode】本地代理增强版分析结束响应