kubectl port-forward在单条转发连接收到工作负载侧tcp rst后，可能报lost connection to pod并结束整个转发会话，后续连接随之被拒绝。kubernetes原帖已有独立复现，维护者接受了问题分类，但截至本轮核验，相关修复pr仍为open，不能宣称某个正式版本已经解决。
修复PR仍为Open，内容为候选方案而非已发布功能
Pod正常也可能中断转发
原报告在kubectl 1.32.1、kind服务端1.32.3等环境给出复现，另有参与者在1.36系列环境复现。测试中Pod保持Running，单次RST仍使本地监听退出；普通FIN关闭则表现不同。这些是原帖记录的具体条件，不代表所有Kubernetes版本和网络实现均已验证。
先区分工作负载和Pod生命周期
出现错误后，先查看Pod是否重启、删除或被同名新Pod替换，再结合服务端连接日志判断是否存在RST。单纯看到lost connection to pod，不能直接认定Pod已经消失。重新运行转发只能恢复会话，不等于修复根因。
为何不是简单忽略错误
一个转发会话共享SPDY或WebSocket连接。当前错误处理可能把一条连接的失败提升为共享会话失败；与此同时，Pod真正终止时又需要结束转发。直接删除关闭逻辑，会破坏另一类必要行为。
原帖分析指出，错误在运行时及转发协议间传递时缺少足够的结构化信息，难以可靠区分工作负载连接错误和Pod或运行时失效。
修复还处于评审阶段
PR #143733提出把单连接错误处理与Pod生命周期监控分开：为调用方提供错误策略，并由Pod监听处理删除、UID变化及状态变化等情况。这些是候选实现，不是已经可用的稳定API承诺。
生产排查应保留kubectl、服务端、容器运行时版本及失败日志，继续跟踪原问题与合并状态。不建议把候选PR代码直接视为厂商已发布修补，也不要用无限重启转发掩盖持续连接异常。
