# WebSocket增强服务技术设计文档

## 概述

本文档详细解释了 `src/services/ws.ts` 的技术设计思路、架构选择和实现细节。这个文件实现了一个增强的WebSocket服务，在保持原有接口不变的前提下，添加了心跳检测、自动重连、错误处理等企业级功能。

## 设计目标

### 主要目标

1. **零侵入性**：业务代码无需修改，完全透明的功能增强
2. **企业级稳定性**：心跳检测、自动重连、错误恢复
3. **可配置性**：全局配置，易于调整和优化
4. **类型安全**：完整的TypeScript类型支持
5. **内存安全**：正确的资源管理，防止内存泄漏

### 兼容性目标

- 保持原有 `create(path): Promise<WebSocket>` 接口不变
- 返回标准WebSocket实例，支持所有原生API
- 业务代码中的 `ws.onmessage`, `ws.close()` 等调用完全兼容

## 架构设计

### 整体架构图

```
┌─────────────────────┐    ┌──────────────────────┐    ┌─────────────────────┐
│   业务代码           │    │  EnhancedWebSocket    │    │   原生WebSocket      │
│                     │    │     (包装器)          │    │                     │
│ ws.onmessage = ...  │───▶│ 事件拦截和过滤        │───▶│ 实际网络连接         │
│ ws.send(data)       │    │ 心跳检测逻辑          │    │                     │
│ ws.close()          │    │ 重连管理             │    │                     │
└─────────────────────┘    └──────────────────────┘    └─────────────────────┘
                                       │
                                       ▼
                           ┌──────────────────────┐
                           │    WS_CONFIG         │
                           │   (全局配置)          │
                           │ - 心跳间隔            │
                           │ - 重连策略            │
                           │ - 超时设置            │
                           └──────────────────────┘
```

### 设计模式选择

#### 1. 包装器模式 (Wrapper Pattern)

```typescript
class EnhancedWebSocket {
  private ws: WebSocket; // 包装原生WebSocket
}
```

**为什么选择包装器而不是继承？**

1. **继承的问题**：

   ```typescript
   // 继承方式的问题
   class EnhancedWebSocket extends WebSocket {
     constructor(url: string) {
       super(url); // 连接立即开始，无法在事件处理器设置前进行拦截
     }
   }
   ```

2. **包装器的优势**：
   ```typescript
   // 包装器方式的优势
   class EnhancedWebSocket {
     constructor(path: string, baseUrl: string) {
       this.ws = new WebSocket(baseUrl + path); // 控制创建时机
       this.setupHandlers(); // 立即设置我们的处理器
     }
   }
   ```

#### 2. 代理模式 (Proxy Pattern)

通过getter/setter拦截用户对事件处理器的设置：

```typescript
get onmessage(): ((event: MessageEvent) => void) | null {
  return this.userOnMessage;
}

set onmessage(handler: ((event: MessageEvent) => void) | null) {
  this.userOnMessage = handler; // 保存用户的处理器
  // 我们的处理器已经在构造时设置，会调用用户的处理器
}
```

## 核心技术实现

### 1. Class 设计选择

#### 为什么使用 Class？

```typescript
class EnhancedWebSocket {
  // 私有状态管理
  private ws: WebSocket;
  private path: string;
  private heartbeatTimer?: NodeJS.Timeout;
  // ...
}
```

**选择Class的原因：**

1. **状态封装**：WebSocket连接需要管理多个状态（连接、定时器、配置等）
2. **方法绑定**：事件处理器需要访问实例状态，Class提供了自然的this绑定
3. **生命周期管理**：连接的创建、维护、销毁有清晰的生命周期
4. **类型安全**：TypeScript对Class有更好的类型推导和检查

**与函数式方案的对比：**

```typescript
// 函数式方案的问题
function createEnhancedWS(path: string) {
  let heartbeatTimer: NodeJS.Timeout;
  let reconnectTimer: NodeJS.Timeout;
  // 需要大量闭包来管理状态，复杂度高
}

// Class方案的优势
class EnhancedWebSocket {
  private heartbeatTimer?: NodeJS.Timeout; // 清晰的状态管理
  private reconnectTimer?: NodeJS.Timeout;
  // 方法可以直接访问状态
}
```

### 2. Private 成员设计

#### 为什么大量使用 private？

```typescript
class EnhancedWebSocket {
  private ws: WebSocket; // 内部WebSocket实例
  private path: string; // 连接路径
  private heartbeatTimer?: NodeJS.Timeout; // 心跳定时器
  private reconnectTimer?: NodeJS.Timeout; // 重连定时器
  private reconnectAttempts: number = 0; // 重连次数
  private isManualClose: boolean = false; // 手动关闭标志
  private isHeartbeatTimeout: boolean = false; // 心跳超时标志
}
```

**Private的重要性：**

1. **封装原则**：防止外部直接访问和修改内部状态
2. **API稳定性**：内部实现可以随时重构，不影响公共接口
3. **状态一致性**：防止外部代码破坏内部状态的一致性
4. **错误预防**：避免用户误用内部API导致的bug

**示例对比：**

```typescript
// 如果没有private，用户可能这样做
const ws = new EnhancedWebSocket('/test');
ws.heartbeatTimer = undefined; // 💥 破坏了心跳检测
ws.reconnectAttempts = -1; // 💥 破坏了重连逻辑

// 有了private，这些操作被编译器阻止
// ✅ 确保了内部状态的安全性
```

### 3. Constructor 设计

#### 构造函数的关键作用

```typescript
constructor(path: string, baseUrl: string) {
  this.path = path;
  this.baseUrl = baseUrl;
  this.ws = new WebSocket(baseUrl + path);  // 创建实际连接
  this.setupHandlers();                     // 立即设置事件处理器
}
```

**设计要点：**

1. **立即执行**：构造时立即创建连接和设置处理器
2. **状态初始化**：确保所有私有状态都有正确的初始值
3. **参数验证**：（可以添加）对输入参数进行验证
4. **最小权限**：只接收必要的参数，其他配置使用全局配置

**为什么不延迟创建连接？**

```typescript
// ❌ 错误方案：延迟创建
constructor(path: string, baseUrl: string) {
  this.path = path;
  this.baseUrl = baseUrl;
  // 不创建连接，等用户调用connect()
}

// ✅ 正确方案：立即创建
constructor(path: string, baseUrl: string) {
  // 立即创建，因为原有接口期望构造后就有连接
  this.ws = new WebSocket(baseUrl + path);
  this.setupHandlers();
}
```

### 4. Getter/Setter 设计

#### 透明的属性代理

```typescript
// 只读属性的getter
get readyState(): number {
  return this.ws.readyState; // 直接代理到内部WebSocket
}

get url(): string {
  return this.ws.url;
}

// 可写属性的getter/setter
get binaryType(): BinaryType {
  return this.ws.binaryType;
}

set binaryType(value: BinaryType) {
  this.ws.binaryType = value;
}
```

**为什么需要这些getter/setter？**

1. **API兼容性**：用户期望能够访问标准WebSocket的所有属性
2. **透明代理**：用户感觉在使用标准WebSocket，实际上是我们的增强版本
3. **状态同步**：确保外部看到的状态与内部WebSocket状态一致

#### 事件处理器的特殊getter/setter

```typescript
// 事件处理器的拦截
get onmessage(): ((event: MessageEvent) => void) | null {
  return this.userOnMessage; // 返回用户设置的处理器
}

set onmessage(handler: ((event: MessageEvent) => void) | null) {
  this.userOnMessage = handler; // 保存用户的处理器
  // 我们的内部处理器会调用用户的处理器
}
```

**关键设计思路：**

1. **双层处理**：我们的处理器 + 用户的处理器
2. **透明性**：用户感觉直接在设置WebSocket的事件处理器
3. **控制权**：我们先处理（如过滤心跳），再传递给用户

### 5. 事件处理架构

#### 事件流设计

```
WebSocket原生事件 → 我们的处理器 → 过滤/处理 → 用户的处理器
```

#### 具体实现

```typescript
private setupHandlers(): void {
  // 1. 设置我们的处理器
  this.ws.onmessage = (event) => {
    const messageData = event.data;

    // 2. 我们先处理（心跳检测）
    let isHeartbeatResponse = false;
    if (typeof messageData === 'string' && messageData === WS_CONFIG.heartbeatResponseType) {
      isHeartbeatResponse = true;
    }

    if (isHeartbeatResponse) {
      this.clearHeartbeatTimeout(); // 清除心跳超时
      return; // 不传递给用户
    }

    // 3. 传递给用户的处理器
    if (this.userOnMessage) {
      this.userOnMessage(event);
    }
  };
}
```

**设计优势：**

1. **消息过滤**：自动过滤心跳消息，用户无感知
2. **状态管理**：自动处理连接状态变化
3. **错误恢复**：自动处理连接错误和重连

### 6. 定时器管理

#### 定时器生命周期管理

```typescript
class EnhancedWebSocket {
  private heartbeatTimer?: NodeJS.Timeout; // 心跳发送定时器
  private heartbeatTimeoutTimer?: NodeJS.Timeout; // 心跳响应超时定时器
  private reconnectTimer?: NodeJS.Timeout; // 重连定时器
}
```

**为什么需要三个定时器？**

1. **heartbeatTimer**：定期发送心跳包
2. **heartbeatTimeoutTimer**：检测心跳响应超时
3. **reconnectTimer**：延迟重连

#### 定时器清理策略

```typescript
// 停止心跳检测
private stopHeartbeat(): void {
  if (this.heartbeatTimer) {
    clearInterval(this.heartbeatTimer);
    this.heartbeatTimer = undefined; // 重置为undefined
  }
  this.clearHeartbeatTimeout(); // 同时清理超时检测
}

// 清除心跳响应超时检测
private clearHeartbeatTimeout(): void {
  if (this.heartbeatTimeoutTimer) {
    clearTimeout(this.heartbeatTimeoutTimer);
    this.heartbeatTimeoutTimer = undefined; // 重置为undefined
  }
}
```

**内存安全保证：**

1. **及时清理**：每次停止时都清理定时器
2. **状态重置**：清理后设置为undefined
3. **多重清理**：在多个关键点都进行清理（连接关闭、手动关闭等）

### 7. 状态标志设计

#### 关键状态标志

```typescript
private isManualClose: boolean = false;       // 是否手动关闭
private isHeartbeatTimeout: boolean = false;  // 是否心跳超时
private reconnectAttempts: number = 0;        // 重连次数
```

**为什么需要这些标志？**

1. **区分关闭原因**：手动关闭 vs 异常断开 vs 心跳超时
2. **重连决策**：根据不同原因决定是否重连
3. **状态跟踪**：跟踪重连进度和次数

#### 状态转换逻辑

```typescript
// 心跳超时时
private startHeartbeatTimeout(): void {
  this.heartbeatTimeoutTimer = setTimeout(() => {
    this.isHeartbeatTimeout = true;  // 设置心跳超时标志
    this.ws.close(1000, 'Heartbeat timeout');
  }, WS_CONFIG.heartbeatTimeout);
}

// 连接关闭时的决策
this.ws.onclose = (event) => {
  // 如果不是手动关闭，或者是心跳超时导致的关闭，则重连
  if (!this.isManualClose || this.isHeartbeatTimeout) {
    this.scheduleReconnect();
  }

  this.isHeartbeatTimeout = false; // 重置标志
};
```

### 8. addEventListener/removeEventListener 实现

#### 为什么需要这些方法？

```typescript
addEventListener<K extends keyof WebSocketEventMap>(
  type: K,
  listener: (this: WebSocket, ev: WebSocketEventMap[K]) => any,
  options?: boolean | AddEventListenerOptions
): void {
  this.ws.addEventListener(type, listener, options);
}

removeEventListener<K extends keyof WebSocketEventMap>(
  type: K,
  listener: (this: WebSocket, ev: WebSocketEventMap[K]) => any,
  options?: boolean | EventListenerOptions
): void {
  this.ws.removeEventListener(type, listener, options);
}
```

**重要性：**

1. **完整的API兼容性**：某些业务代码可能使用addEventListener而不是onXXX
2. **事件管理**：支持多个监听器
3. **标准兼容**：遵循WebSocket标准API

**类型安全：**

- 使用泛型 `<K extends keyof WebSocketEventMap>` 确保事件类型正确
- listener参数的类型根据事件类型自动推导

### 9. 心跳检测机制

#### 心跳超时检测逻辑

```typescript
// 发送心跳时，只在没有超时检测时才设置新的
this.heartbeatTimer = setInterval(() => {
  if (this.ws.readyState === WebSocket.OPEN) {
    this.ws.send(WS_CONFIG.heartbeatMessage);

    if (!this.heartbeatTimeoutTimer) {
      // 关键：避免重复设置
      this.startHeartbeatTimeout();
    }
  }
}, WS_CONFIG.heartbeatInterval);
```

**设计要点：**

1. **避免重复设置**：只有在没有超时检测时才设置新的
2. **超时逻辑**：设定时间内没收到响应就断开连接
3. **状态同步**：收到响应时清除超时检测

#### 心跳响应处理

```typescript
// 检查是否为心跳响应（支持字符串和JSON格式）
let isHeartbeatResponse = false;

// 1. 检查简单字符串格式
if (typeof messageData === 'string' && messageData === WS_CONFIG.heartbeatResponseType) {
  isHeartbeatResponse = true;
}

// 2. 检查JSON格式
if (!isHeartbeatResponse && typeof messageData === 'string') {
  try {
    const data = JSON.parse(messageData);
    if (data.type === WS_CONFIG.heartbeatResponseType) {
      isHeartbeatResponse = true;
    }
  } catch (e) {
    // JSON解析失败，不是JSON格式的心跳响应
  }
}
```

**兼容性设计**：支持两种心跳响应格式，适应不同的服务器实现。

### 10. 重连机制

#### 指数退避算法

```typescript
private scheduleReconnect(): void {
  if (this.isManualClose || this.reconnectAttempts >= WS_CONFIG.maxReconnectAttempts) {
    return;
  }

  this.reconnectAttempts++;

  // 指数退避重连策略
  const delay = Math.min(
    WS_CONFIG.reconnectBaseDelay * Math.pow(2, this.reconnectAttempts - 1),
    WS_CONFIG.maxReconnectDelay
  );

  this.reconnectTimer = setTimeout(() => {
    this.reconnect();
  }, delay);
}
```

**算法解释：**

- 第1次重连：1000ms 后
- 第2次重连：2000ms 后
- 第3次重连：4000ms 后
- 第4次重连：8000ms 后
- 第5次重连：16000ms 后（受maxReconnectDelay限制，实际为30000ms）

**设计考虑：**

1. **指数退避**：避免对服务器造成压力
2. **最大延迟限制**：防止延迟过长
3. **次数限制**：避免无限重连
4. **服务器友好**：给服务器恢复时间

### 11. 类型安全设计

#### 严格的类型定义

```typescript
// 事件处理器类型
private userOnMessage: ((event: MessageEvent) => void) | null = null;
private userOnClose: ((event: CloseEvent) => void) | null = null;
private userOnError: ((event: Event) => void) | null = null;
private userOnOpen: ((event: Event) => void) | null = null;
```

**类型安全的好处：**

1. **编译时检查**：在编译时捕获类型错误
2. **IDE支持**：更好的自动补全和错误提示
3. **重构安全**：类型系统确保重构的正确性

#### 泛型的使用

```typescript
addEventListener<K extends keyof WebSocketEventMap>(
  type: K,
  listener: (this: WebSocket, ev: WebSocketEventMap[K]) => any,
  options?: boolean | AddEventListenerOptions
): void
```

**泛型的价值：**

- `K extends keyof WebSocketEventMap`：确保事件类型只能是WebSocket支持的类型
- `ev: WebSocketEventMap[K]`：根据事件类型自动推导事件对象类型

### 12. 资源管理

#### 完整的清理机制

```typescript
close(code?: number, reason?: string): void {
  console.log(`手动关闭WebSocket: ${this.path}`);
  this.isManualClose = true;
  this.isHeartbeatTimeout = false; // 重置心跳超时标志
  this.stopHeartbeat();            // 清理心跳定时器
  this.clearReconnectTimer();      // 清理重连定时器
  this.ws.close(code, reason);     // 关闭实际连接
}
```

**资源清理的重要性：**

1. **内存泄漏预防**：确保所有定时器都被清理
2. **状态一致性**：重置所有状态标志
3. **优雅关闭**：按正确顺序清理资源

## 配置设计

### 全局配置对象

```typescript
const WS_CONFIG = {
  heartbeatInterval: 3000, // 心跳间隔
  heartbeatTimeout: 5000, // 心跳响应超时时间
  maxReconnectAttempts: 5, // 最大重连次数
  reconnectBaseDelay: 1000, // 重连基础延迟
  maxReconnectDelay: 30000, // 最大重连延迟
  heartbeatMessage: 'ping', // 心跳消息
  heartbeatResponseType: 'pong', // 心跳响应类型
};
```

**配置设计原则：**

1. **集中管理**：所有配置在一个地方，易于维护
2. **合理默认值**：开箱即用的配置
3. **易于调整**：生产环境可以快速调整参数
4. **文档化**：每个配置都有清晰的注释

## 接口兼容性

### 原有接口保持不变

```typescript
// 原有接口
function create(path: string): Promise<WebSocket> {
  const baseUrl = import.meta.env.ENV_WEBSOCKET_BASE ?? '';
  const ws = new EnhancedWebSocket(path, baseUrl) as any;

  return new Promise((resolve, reject) => {
    const timeout = setTimeout(() => {
      ws.close();
      reject(new Error('WebSocket connection timeout'));
    }, 10000);

    ws.addEventListener('open', () => {
      clearTimeout(timeout);
      resolve(ws); // 返回增强的WebSocket，但类型为WebSocket
    });

    ws.addEventListener('error', (e: any) => {
      clearTimeout(timeout);
      reject(e);
    });
  });
}
```

**兼容性保证：**

1. **相同的函数签名**：`create(path: string): Promise<WebSocket>`
2. **相同的返回类型**：返回Promise<WebSocket>
3. **相同的使用方式**：业务代码无需任何修改

## 总结

### 技术选择总结

| 技术选择      | 原因                             | 替代方案     | 为什么不选择替代方案    |
| ------------- | -------------------------------- | ------------ | ----------------------- |
| Class         | 状态封装、方法绑定、生命周期管理 | 函数+闭包    | 复杂度高，类型支持差    |
| 包装器模式    | 控制创建时机、事件拦截           | 继承         | 无法在事件设置前拦截    |
| Private成员   | 封装、API稳定性、状态保护        | Public成员   | 容易被误用，状态不安全  |
| Getter/Setter | 透明代理、API兼容性              | 直接方法     | 不符合WebSocket API习惯 |
| 多定时器      | 职责分离、精确控制               | 单定时器     | 逻辑混乱，难以维护      |
| 状态标志      | 精确控制重连逻辑                 | 仅依赖状态码 | WebSocket状态码限制多   |

### 架构优势

1. **零侵入性**：业务代码完全无需修改
2. **高可靠性**：多重保障确保连接稳定
3. **高可维护性**：清晰的架构和完整的类型支持
4. **高性能**：最小的性能开销
5. **高扩展性**：易于添加新功能

### 最佳实践体现

1. **单一职责原则**：每个方法只负责一个功能
2. **开闭原则**：对扩展开放，对修改封闭
3. **依赖倒置原则**：依赖抽象（接口）而非具体实现
4. **接口隔离原则**：用户只看到需要的接口
5. **里氏替换原则**：增强版本完全可以替换原版本

这个实现展示了如何在保持向后兼容的同时，提供企业级的功能增强，是一个很好的渐进式增强的例子。