流式响应中间件是带过滤网的传送带，负责接收、切片、转发模型输出并执行审核决策；它不直接审查，而是调度安全护栏服务，按固定阈值或滑动窗口策略切片，结合chatId等上下文参数实现低延迟、高隐蔽性的内容风控。
流式响应中间件本身不直接做内容审查，但它提供了关键的“拦截点”——在模型输出到达前端前，把每一段流式数据截下来送审。真正的审查动作由独立的安全护栏服务完成，中间件只负责调度、切片、转发和结果决策。
流式中间件的核心角色：管道与闸门
它不是审核员，而是带过滤网的传送带：
- 接收大模型返回的原始流（如 text/event-stream 或 chunked transfer）
- 按策略将连续字节流切分为语义合理的片段（如每150字符或每句标点后）
- 同步将每个片段发给审核服务（如 response_security_check_hp），并阻塞/等待其返回
- 根据审核结果决定：放行、截断、替换、撤回已显示内容
- 将处理后的数据继续以流式格式推给前端（保持 SSE 或 Fetch Stream 格式不变）
内容切片策略直接影响审查效果
切得太粗，风险内容可能整段透出；切得太细，上下文断裂导致误判。主流做法有两种：
- 固定阈值切片：例如累计满200字符触发一次审核。实现简单，适合对延迟不敏感、语义依赖弱的场景（如客服话术模板生成）
- 滑动窗口切片：每新增60字符就送检最近300字符。保留上下文，能识别“逐步诱导”类违规，推荐用于教育、金融等高敏领域
注意：高性能审核服务 response_security_check_hp 目前仅适配固定阈值模式，选型时需匹配。
立即学习“前端免费学习笔记（深入）”；
前端配合：让审查对用户“隐形”
审查过程必须快（建议单次 ≤100ms），否则用户会感知卡顿。前端要支持三种状态渲染：
- 正常流式追加：审核通过 → 直接 append 到消息区
- 风险中断：收到“阻断”指令 → 立即清空最后一段暂存内容，显示“内容不符合规范”提示
- 合规代答：审核返回预设话术 → 替换当前待渲染区块，不暴露原始风险文本
用 Fetch + ReadableStream 实现时，可在 decoder.decode 后、更新 DOM 前插入审核回调；用 SSE 时，则在 onmessage 中解析 data 字段后调用审核钩子。
关键参数与上下文关联
单靠文本片段无法判断风险，必须传上下文标识：
- chatId：唯一标记本轮对话，确保多轮切片可关联分析
- done：标记是否为本轮最终片段，便于审核系统做终局判定
- user_role / scene（可选）：标注用户身份或业务场景，辅助策略分级（如学生账号禁用成人话题）
这些字段需由中间件统一注入请求体，传递给审核服务，而非由前端拼接。
