流式切片中“半个 Token”断句源于数据边界与语义边界不重合，需通过正则识别完整token、缓存未闭合片段、跨块拼接校验及超时/长度兜底策略实现安全恢复。
流式切片中出现“半个 Token”断句，本质是数据边界与语义边界不重合——比如网络分包、日志缓冲区截断、或逐块读取大文本时，一个完整 token（如带引号的字符串、JSON 字段、命令行参数）被硬生生切在中间。正则表达式本身不能“预测未到达的内容”，但可以配合策略规避误切、识别残缺、并安全恢复。关键不在“一刀切”，而在“识别+缓存+拼接”。
用正则识别 token 边界，而非依赖固定分隔符
传统 split("\s+") 会把 "file name.txt" 拆成两个碎片；而流式场景更危险：可能只收到 "file na 就断了。正确做法是用正则主动匹配完整 token：
-
匹配模式优先选
"[^"]*"、'[^']*'、\S+—— 这三类覆盖了引号包裹内容和普通非空字段，且每个 match 都是自封闭的 - 避免用
split()做流式切分；改用Pattern.compile(...).matcher(input).find()逐个提取，天然跳过不完整片段 - 若当前块末尾停在引号开头（如
"file）、或反斜杠结尾（如file），说明 token 未闭合，需缓存等待下一块
维护上下文状态，标记“待续 Token”
流式处理必须保留状态。遇到以下情况，不输出 token，而是暂存并标记类型：
- 末字符是
"或'，且前面没有配对的起始引号 → 视为新引号开始，但尚未收尾 - 末字符是
\（转义符）→ 后续字符应与其合并，例如file name应为一个 token - 末字符是
{、[、(等结构起始符 → 可能是 JSON/嵌套结构开头，需计数匹配
跨块拼接时做最小化校验，拒绝非法续接
下一块到来后，不是简单拼接，而是检查是否构成合法 token：
- 若上块以
"结尾，本块以非"开头 → 先拼接，再用"[^"]*"尝试匹配整个字符串；若失败，继续缓存 - 若上块是
file\，本块是name.txt→ 合并为file ame.txt，再按规则解析（注意反斜杠转义逻辑） - 若拼接后仍无闭合引号或括号，且长度超阈值（如 > 10KB），可判定为异常输入，丢弃或报错
预设安全兜底：超时/长度限制触发强制 flush
防止缓存无限增长：
- 设置最大缓存时间（如 500ms）或最大字节（如 8KB），到期或超限时，将当前缓存作为不完整 token 输出（加标记如
[INCOMPLETE]） - 对日志类场景，可输出警告并补全换行符或占位符，保证下游解析器不卡死
- 不追求 100% 还原，而确保“不断链、不崩溃、可追溯”
