网关日志最后只写了半条，采集器怎样保留待完成记录

持续追加的网关日志读到文件尾，只说明此刻没有更多字节，不一定代表最后一条记录已经写完。本文给采集器定义LF作为提交标记：完整行才解码并验证对象，末尾字节原样待续。这个追加合同不等于JSON Lines标准要求末行必须有换行。

暂时EOF与完整快照结束分开处理

附件先提供一条完整e1和e2的半条尾部。第一次读取后只能提交e1，e2尾部保存在bytearray里，不补引号、不补花括号，也不把它当成一条失败业务事件输出。再次读取空字节时，已提交数和待续原始字节都应保持不变，不能因为轮询一次EOF就清空缓存。

后续追加剩余文本和LF后，e2才完成并提交。结果ID为e1、e2，合计两条；再读EOF不会重复提交。运行器输出待续部分的十六进制和长度，可以逐字节与原输入核对，避免把“暂时没法解析”处理成丢弃内容。未完成记录的保留期限与最大大小仍需在实际采集器另设预算。

先找物理行，再处理业务对象

本参考器只在收到LF后切出一行，再做UTF-8解码和JSON解析，最后要求结果为对象。这是网关日志schema的额外限制；JSON Lines允许其他合法JSON值，不能把本地对象要求说成标准禁止数字或null。遇到完整但无效的行，应保留证据并按错误策略处理，不能为了继续读取任意修补原文。

同一字节流分别整块、逐字节和三段送入，最终对象集合必须相同。逐字节切分可能落在汉字编码内部，但采集器未到行提交点前只保留字节，不尝试凭半个字符猜业务内容。这里关注服务端追加文件的提交与保留，不承担SSE帧恢复或AI客户端输出解析任务。

完整末行无LF也可能是标准合法文件

JSON Lines说明末行终止符推荐但不强制。附件因此另有一个完整JSON对象却不带LF的对照：作为固定快照它可以是合法末行，但本持续追加tailer按自己的合同先等待，追加LF才提交一次。若以后支持“文件已封存”的最终读取，应另定义封存信号与末行策略，不能把暂时EOF当成封存。

本批实际运行内存字节缓冲和对象解析，未访问生产日志，也没有测试文件轮转、截断或多进程并写。真实采集器还需维护文件身份、偏移和待续缓冲的生命周期，防止换文件后把旧尾巴拼到新文件头。先把追加时哪些字节已提交、哪些仍待完成记录清楚，才能在停写、重启或异常中保留可解释的日志边界。

配套样本与复核入口

下载本篇独立合成输入和实验运行器。上述文件放在同一目录后运行 python run_lab.py C015。完整运行需要全部四十四份输入及相关配置。结果中的method区分离线计算、静态参考检查与回环实测，不能把前两者当成真实网关已通过。

资料核对日期：2026-10-24。官方依据1；官方依据2。

与本站相关基础教程的区别：旧文讲SSE业务流超时/末帧；新题专查服务端持续追加日志的提交和待完成尾部，不恢复旧UTF8客户端增量解码主问。