轻量后端在演示之外的验证本地 Demo 能流式返回文字只说明一条成功路径成立。真实环境里客户端会中途关闭页面上游会超时或拒绝请求代理会缓冲响应多个用户会同时发起长连接。轻量后端要面对这些边界关键不是加上更多框架而是把一次请求的生命周期、并发预算、取消方式和错误状态写清楚并用可控测试验证。每条流都应有明确的生命周期流式请求开始后服务需要知道谁拥有取消权、客户端断开时如何通知上游、完成或失败后怎样释放计数和监听器。HTTP 请求的close、aborted与响应结束事件并不完全等价具体监听方式要依赖所用运行时和框架验证不要只靠一个全局计数器推断所有请求状态。取消上游请求前后都应检查幂等性防止重复释放或把完成请求误记为失败。客户端断开时停止继续生成通常能节省资源但上游服务是否立即取消、已产生的用量如何计费要以供应商和协议行为为准。服务端应记录脱敏的运行标识、阶段耗时、取消原因和最终状态而不是把完整 prompt 或访问令牌写入日志。用户重新连接时需要由产品定义是重新发起、恢复任务还是查看已完成部分不能把临时连接状态当作永久会话。请求准入 → 建立取消信号 → 上游流式读取 → 写入与背压 → 完成/错误/取消 → 释放资源并记录状态这条链路的每一步都应能在测试中观察。只在浏览器里看一次流式动画无法证明断流后资源已释放也无法证明异常不会留下悬挂任务。并发和背压要按系统整体预算设计为流式请求设置并发上限时考虑模型连接、内存、代理、数据库和外部服务的共同容量。单进程内的计数器在多实例部署时只能限制本实例若需要全局配额应使用适合的协调机制并处理其不可用情况。达到上限时返回何种状态、是否允许排队、队列多长、用户何时可以重试都应事先定义。res.write()返回 false 时等待 drain 是基本的背压处理但还要处理客户端已断开、drain 永远不来和上游持续产出的情况。给请求设置总 deadline、每阶段超时和取消传播不要为了保持流畅而无限等待。对工具调用或写入型请求流中断后需要查询最终状态或使用幂等键避免重试造成重复副作用。代理与部署配置需要实测SSE 经过反向代理、CDN 或负载均衡时缓冲、空闲超时和连接限制可能改变表现。是否关闭代理缓冲、是否发送心跳、超时设多长都应结合平台文档和目标网络验证而不是把一组配置当作通用模板。心跳有额外流量和日志成本也不一定能穿透所有中间层。进程守护和内存限制可以缩小单次故障影响却不能替代泄漏定位或正确释放。自动重启前要确认请求如何迁移、用户会看到什么、日志和诊断材料是否保留。容器或平台的健康检查也应区分进程存活与是否还能安全接收新流量。以失败路径验收轻量服务在隔离环境中测试客户端在不同阶段取消、上游超时和返回格式错误、并发接近预算、代理延迟写入、服务重启以及恢复后的状态。记录客户端成功、取消、错误和资源使用而不只看吞吐或控制台有没有未捕获异常。测试速率、输入大小、持续时间和停止条件应明确避免压测本身掩盖问题。上线后通过小范围流量观察连接数、请求阶段耗时、取消比例、错误类别和资源趋势并保留回退入口。未能复现的异常要记录条件和缺失证据不能据此宣称已彻底解决。轻量服务的可靠性来自边界清楚、状态可恢复、失败可解释而不是 Demo 时看起来足够流畅。