默认绑定不参与断线重连，真正起作用的是状态机对上下文生命周期的显式管理；常见情形包括DI容器的Singleton/Scoped绑定、AsyncLocal/contextvars隐式传递、对象字段天然驻留；核心在于明确定义上下文数据的初始化、暂存与恢复时机。
默认绑定特性本身不直接参与断线重连或上下文保护——它属于语言层（如 C# 的 default 关键字、TypeScript 的类型推导默认值、或某些框架中“未显式配置时采用内置行为”的约定），而非网络状态机的运行机制。真正起作用的是**状态机设计中对上下文生命周期的显式管理策略**，配合语言/框架提供的绑定、作用域和资源隔离能力。
明确“默认绑定”在通信上下文中的实际含义
在多数工程实践中，“默认绑定”指以下几种常见情形：
- 连接对象（如
TcpClient或WebSocket实例）未被显式释放时，由 GC 或 RAII 自动回收 —— 这反而会破坏上下文，不可依赖； - 依赖注入容器中，服务注册为
Singleton或Scoped后，框架自动绑定实例到对应生命周期 —— 这才是可利用的“默认绑定”； - 协程/任务上下文（如 C# 的
AsyncLocal<T>、Python 的contextvars）在未手动清除时沿异步链路隐式传递 —— 属于运行时默认行为，需主动维护； - 状态机类的字段（如
_sessionToken、_reconnectCount）在构造后一直驻留于实例内存中 —— 这是面向对象的天然绑定，但需确保实例不被意外重建。
用 Singleton 服务绑定全局通信上下文
将长连接状态、重连计数、心跳时间戳、最后收到消息 ID 等关键数据封装进一个单例服务，并通过 DI 容器注入到状态机、心跳模块、重连逻辑中：
- 避免每次重连都新建状态机实例，而是复用同一个上下文实例；
- 在连接断开时不清空上下文，仅重置连接句柄（如
_stream = null），保留会话标识与历史状态； - 配合
IHostedService或后台线程守护，确保该服务随应用生命周期存活，不因连接波动而销毁。
用 AsyncLocal/contextvars 隔离并发连接上下文
当单个进程需管理多个设备连接（如 IoT 网关）时，不能共用全局单例，此时需按连接维度隔离上下文：
- C# 中使用
AsyncLocal<ConnectionContext>，在每次ConnectAsync()前设置，后续所有异步操作自动继承； - Python 中用
contextvars.ContextVar存储当前连接的 session_id、last_seq、retry_backoff； - 关键点：必须在每次新连接建立时显式绑定（不是“默认”发生），并在连接关闭后清理，否则可能跨连接泄漏数据。
状态机内部做上下文快照与恢复
断线重连本质是状态迁移（Connected → Disconnected → Connecting → Connected），上下文保护即保证迁移前后关键数据一致：
- 在进入
Disconnected状态前，将待同步的序列号、未确认消息队列、认证票据等序列化暂存（内存或轻量持久化）； - 重连成功后，在
Connected状态入口处主动恢复这些字段，而非依赖“默认”残留； - 避免把上下文绑定到 socket 句柄本身（易失效），而应绑定到更高层的逻辑连接实体（如
DeviceSession类）。
不复杂但容易忽略：上下文不是靠“默认”保存下来的，而是靠你定义清楚哪些数据属于连接生命周期、在哪里初始化、在哪里暂存、在哪里恢复。绑定只是手段，意图才是核心。
