后端微服务云原生【免费下载链接】midway A Node.js Serverless Framework for front-end/full-stack developers. Build the application for next decade. Works on AWS, Alibaba Cloud, Tencent Cloud and traditional VM/Container. Super easy integrate with React and Vue. 项目地址https://gitcode.com/gh_mirrors/mi/midway点击查看免费下载本文以 packages/ws/CHANGELOG.md 为时间主线梳理 Midway 3.x 中midwayjs/ws组件从诞生到成熟的完整演进路径WebSocket 支持何时引入、连接/消息中间件与守卫guard如何落地、底层 ws 库为何一路升级到 v8。并结合 framework.ts、interface.ts、configuration.ts 及测试夹具讲清楚升级鉴权、心跳检测、事件绑定、响应分发等核心机制在源码层面的实现原理。读完本文你将掌握midwayjs/ws的能力边界、配置参数与控制器编写范式能够独立评估和升级你的 WebSocket 应用。一、版本演进总览一份 CHANGELOG 背后的功能脉络midwayjs/ws的 CHANGELOG 是典型的 Conventional Commits 生成日志绝大多数条目是 Version bump only纯版本号递增、无代码变更但其中穿插的关键条目恰恰勾勒出该组件最重要的功能里程碑版本日期关键变更类型2.11.02021-06-10add ws support首次为 Midway 引入 WebSocket 框架能力Feature2.10.72021-04-17add event name args为事件绑定补充事件名参数Fix3.0.0-beta.72021-12-03middleware with ctx.body消息中间件支持ctx.body交互Fix3.0.0-beta.142022-01-04update dependency ws to v8底层 ws 库升级至 v8 大版本Fix3.4.0-beta.72022-07-12support socket connection and message middleware连接与消息双通道中间件Feature3.6.02022-10-10add guard引入守卫机制Feature3.7.02022-10-29纯版本号更新Note从这张表可以清晰看出midwayjs/ws的能力演进顺序先打通连接再补充事件参数随后完善中间件体系接着升级底层依赖到 ws v8最后引入守卫。值得注意的是CHANGELOG 在 2.10.x 及更早版本中混入了midwayjs/socketio的版本记录如 Version bump only for package midwayjs/socketio这反映了 monorepo 早期两包共用发布节奏的历史阅读时可留意区分。当前仓库中 package.json 显示的版本为4.2.3依赖ws8.21.0且声明了node 20的运行时要求——说明从 v3 一路走来的 ws v8 依赖策略延续至今。二、2.11.0WebSocket 支持是如何被引入 Midway 的CHANGELOG 最早的重大功能条目是 2.11.0 的 add ws supportissue #1058。它标志着 Midway 正式具备了原生 WebSocket 场景能力与 koa、express、egg 等传统 Web 场景并列。从 index.ts 的导出结构可以确认组件形态export { MidwayWSFramework as Framework } from ./framework; export * from ./interface; export { WebSocketConfiguration as Configuration } from ./configuration;组件由三部分组成MidwayWSFramework框架主体被Framework()装饰器标注、WebSocketConfiguration组件配置声明namespace: webSocket、以及对外暴露的类型定义。这意味着在业务侧只需在src/configuration.ts中通过imports引入midwayjs/ws框架层就会自动扫描注册的 WS 控制器并挂载 WebSocket 服务。与 HTTP 服务器共享端口的设计在 framework.ts 的run()方法中可以看到一个关键设计决策WebSocket 服务并不总是独立端口而是优先复用 HTTP 服务器if (!this.configurationOptions.port) { server this.applicationContext.get(HTTP_SERVER_KEY); this.logger.info([midway:ws] WebSocket server find shared http server and will be attach.); } else { server this.configurationOptions.server ?? http.createServer(); }即配置了port则自建 HTTP server 独立监听未配置port则从容器中取出 koa/express 等已启动的 HTTP server在其上监听upgrade事件完成 WebSocket 握手。这正是测试夹具 base-app/src/configuration.ts 中显式配置port: 3000的原因——独立端口便于单测环境启动。noServer: true与手动握手组件初始化时applicationInitialize强制noServer true不依赖 ws 库自动监听而是自行接管握手流程。随后框架通过loadMidwayController()读取WS_CONTROLLER_KEY元数据注册的控制器并绑定connection事件这一阶段已经能支撑基础的连接、收发、断开流程。三、3.4.0-beta.7连接中间件与消息中间件的双层体系如果说 2.11.0 打通了能用3.4.0-beta.7 的 support socket connection and message middlewareissue #1984则让midwayjs/ws进入好用阶段。它引入了两条独立的中间件通道连接中间件connection middleware作用于连接建立阶段在事件处理器运行前执行适合做连接级鉴权、日志、初始化消息中间件message middleware作用于每条消息处理链路与 koa 风格的洋葱模型一致适合做消息解析、校验、透传。连接中间件的注册与执行框架在 applicationInitialize 中向应用对象注入了三个扩展方法useConnectionMiddleware、getConnectionMiddleware、onWebSocketUpgrade。其中连接中间件通过独立的connectionMiddlewareManager管理framework.tspublic useConnectionMiddleware(middleware) { this.connectionMiddlewareManager.insertLast(middleware); }在每次新连接到达时addNamespace 内框架将全局连接中间件 控制器级连接中间件合并通过middlewareService.compose组装后执行并且整个连接回调被包在traceService.runWithEntrySpan(ws.connect ...)中自动生成ws.connect链路追踪 Span。消息中间件与事件绑定消息处理走的是另一条链路framework.ts框架根据控制器上OnWSMessage(eventName)元数据用socket.on(messageEventName, handler)绑定监听处理器内部再组合控制器级中间件 事件级中间件 目标方法同样以compose方式串行执行并用ws.message ${eventName}作为追踪 Span 名。值得注意的一个兼容细节处理器根据消息最后一个参数是否为函数自动区分ack 回调最后参数是函数则直接回传结果供客户端做请求-响应式通信与emit 广播否则走响应分发逻辑。这与 2.10.7 中 add event name args 修复一脉相承——事件处理器可以拿到完整的事件名参数。四、3.6.0守卫Guard如何参与 WebSocket 调用链3.6.0 的 add guardissue #2345把 Midway 3.x 的守卫机制带入了 WebSocket 场景。在连接事件处理中framework.ts事件处理器被组装时会在目标方法前插入守卫检查const isPassed await this.app.getFramework().runGuard(ctx, target, wsEventInfo.propertyName); if (!isPassed) { throw new MidwayInvokeForbiddenError(wsEventInfo.propertyName, target); }守卫通过runGuard统一执行失败时抛出MidwayInvokeForbiddenError中断调用。这使鉴权逻辑可以从中间件中剥离以声明式守卫的形式复用同一套规则与 HTTP 场景保持一致的心智模型。升级前鉴权握手阶段的另一道防线除了连接事件内的守卫框架还提供握手阶段的onWebSocketUpgrade钩子framework.ts 与接口定义 interface.tsexport type UpgradeAuthHandler ( request: IncomingMessage, socket: any, head: Buffer ) Promiseboolean;在server.on(upgrade)回调中framework.ts若设置了该 handler则先执行鉴权返回false或抛出异常时直接socket.destroy()拒绝握手通过后才调用this.app.handleUpgrade完成协议升级并发出connection事件。这样便形成了握手鉴权拦截未授权连接 守卫控制事件执行的双层安全模型。五、底层依赖演进ws 库从 v7 到 v8 的升级之路CHANGELOG 中占比最大的实质变更类型是依赖升级全部指向同一个库——ws版本升级目标3.0.0-beta.14ws v8大版本升级#14883.0.1ws v8.4.23.0.4ws v8.5.03.4.0-beta.10ws v8.8.13.5.3ws v8.9.0midwayjs/ws直接构建在ws库之上WebSocket.Server、socket.ping/pong、terminate、readyState等均为底层 API见 framework.ts 的import * as WebSocket from ws。升级到 v8 意味着框架可以获得更严格的消息处理、更好的性能与更完整的类型定义。当前仓库 package.json 已将ws锁定在8.21.0并配套types/ws8.5.14提供 TypeScript 类型支持——在阅读历史版本时若遇到与底层握手或心跳相关的问题可优先对照当时代入的 ws 版本行为差异。六、源码级原理midwayjs/ws的核心运行时机制综合 framework.ts 全文可以将组件运行时拆解为五个环节初始化applicationInitialize创建WebSocket.Server({ noServer: true })注入三个扩展方法扫描 WS 控制器握手run()内server.on(upgrade)可选升级鉴权 →handleUpgrade→ 触发connection连接上下文addNamespace的 connection 回调创建匿名请求上下文注册socket、request、app到请求级容器socket.requestContext使控制器内Inject() ctx可注入IMidwayWSContext事件绑定按WS_EVENT_KEY元数据遍历将OnWSConnection/OnWSMessage/OnWSDisConnection分别映射到connection、自定义消息事件、close响应分发bindSocketResponse处理器返回值根据事件元数据决定去向——EMIT回发当前连接、BROADCAST遍历app.clients中所有readyState WebSocket.OPEN的连接广播均通过runWithExitSpan(ws.emit ...)打点追踪没有WSBroadcast/WSEmit装饰器时默认直接回发本连接。响应格式统一经过formatResultframework.ts对象类型自动JSON.stringify其余原样发送——这正是测试中客户端收到{name:harry,result:6}JSON 字符串的原因。七、配置项详解来自 configuration.ts 与 interface.ts 的权威参数组件默认配置定义在 configuration.tsConfiguration({ namespace: webSocket, importConfigs: [{ default: { webSocket: { enableServerHeartbeatCheck: false, serverHeartbeatInterval: 30000, }, midwayLogger: { clients: { wsLogger: { fileLogName: midway-ws.log }, }, }, }, }], }) export class WebSocketConfiguration {}完整可配置项见 interface.ts 的IMidwayWSConfigurationOptions配置项默认值说明enableServerHeartbeatCheckfalse是否启用服务端心跳检测serverHeartbeatInterval30000心跳检测间隔毫秒port无指定端口时独立监听缺省时复用 HTTP serverserver无自定义 HTTP server 实例pubClient/subClient无预留的发布/订阅客户端广播扩展其余ws.ServerOptions—透传给底层WebSocket.Server如maxPayload等心跳机制在 startHeartBeat 中实现周期性遍历所有连接若某连接isAlive false则terminate()清理否则置为false并发送ping()客户端回pong时connection 回调内socket.on(pong)恢复isAlive true。测试夹具 base-app-heartbeat/src/configuration.ts 将间隔设为1000ms 以加速验证。八、实战用 midwayjs/ws 编写一个 WS 控制器以仓库测试夹具 api.ts 为例一个完整的 WS 控制器长这样import { Inject, OnWSConnection, OnWSDisConnection, OnWSMessage, Provide, WSController } from midwayjs/core; import { IMidwayWSContext } from midwayjs/ws; Provide() WSController() export class APIController { Inject() ctx: IMidwayWSContext; Inject() userService: UserService; OnWSConnection() init(socket, request) { // 连接建立时触发可拿到 socket 与 HTTP 握手请求 } OnWSMessage(message) async gotMyMessage(data) { // 收到 message 事件返回值自动回发可配合 WSEmit / WSBroadcast 控制分发 return { name: harry, result: parseInt(data) 5 }; } OnWSDisConnection() disconnect(id: number) { // 连接断开时触发 } }配套的 index.test.ts 验证了三类行为客户端发送1收到{name:harry,result:6}消息回发base-app-broadcast夹具下两个客户端同时收到广播total 12即 66 双端累加base-app-filter夹具验证中间件可将消息拦截改写为packet error心跳测试则确认客户端能收到ping帧。这些测试全部通过midwayjs/mock的createWebSocketClient与createLightApp在纯 Node 环境运行不需要真实浏览器。九、小结从 CHANGELOG 读懂组件的成熟路径回看 CHANGELOG.mdmidwayjs/ws的演进是一套典型的基础设施逐步完善路径先接入2.11.0→ 补齐事件参数2.10.7→ 升级底层 ws v83.0.0-beta.14→ 完善中间件3.4.0-beta.7→ 引入守卫3.6.0期间伴随多次依赖修补与 monorepo 版本同步。对于正在使用或计划引入midwayjs/ws的开发者本文梳理的配置参数、控制器范式、双层中间件与双层鉴权模型可直接映射到 framework.ts 与 interface.ts 的源码中进行二次确认做到文档有据、源码可查。赞分享后端微服务云原生【免费下载链接】midway A Node.js Serverless Framework for front-end/full-stack developers. Build the application for next decade. Works on AWS, Alibaba Cloud, Tencent Cloud and traditional VM/Container. Super easy integrate with React and Vue. 项目地址https://gitcode.com/gh_mirrors/mi/midway点击查看免费下载相关推荐Midway 安全组件 midwayjs/security 全解析从演进历史到配置实战Midway 安全组件 midwayjs/security 全解析从演进历史到配置实战 midwayjs/security 是 Midway 框架内置的通后端微服务云原生Midway gRPC 组件能力演进全解析从框架引入到 Stream API 与 Guard 支持Midway gRPC 组件能力演进全解析从框架引入到 Stream API 与 Guard 支持 导读 本文以 packages/grpc/CHANGELO后端微服务云原生Midway 核心包演进全解析从 midwayjs/core 的变更日志看 IoC 容器与 Web 框架的架构变迁Midway 核心包演进全解析从 midwayjs/core 的变更日志看 IoC 容器与 Web 框架的架构变迁 导读 packages/core/CHA后端微服务云原生上一篇TiXL 交互 Gizmo 指南在输出视口中直接拖拽操控三维对象下一篇FF14钓鱼计时器「渔人的直感」使用教程从错过鱼王到轻松收杆创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Midway WebSocket 框架演进全解析：从 @midwayjs/ws 的引入、中间件到守卫体系
后端微服务云原生【免费下载链接】midway A Node.js Serverless Framework for front-end/full-stack developers. Build the application for next decade. Works on AWS, Alibaba Cloud, Tencent Cloud and traditional VM/Container. Super easy integrate with React and Vue. 项目地址https://gitcode.com/gh_mirrors/mi/midway点击查看免费下载本文以 packages/ws/CHANGELOG.md 为时间主线梳理 Midway 3.x 中midwayjs/ws组件从诞生到成熟的完整演进路径WebSocket 支持何时引入、连接/消息中间件与守卫guard如何落地、底层 ws 库为何一路升级到 v8。并结合 framework.ts、interface.ts、configuration.ts 及测试夹具讲清楚升级鉴权、心跳检测、事件绑定、响应分发等核心机制在源码层面的实现原理。读完本文你将掌握midwayjs/ws的能力边界、配置参数与控制器编写范式能够独立评估和升级你的 WebSocket 应用。一、版本演进总览一份 CHANGELOG 背后的功能脉络midwayjs/ws的 CHANGELOG 是典型的 Conventional Commits 生成日志绝大多数条目是 Version bump only纯版本号递增、无代码变更但其中穿插的关键条目恰恰勾勒出该组件最重要的功能里程碑版本日期关键变更类型2.11.02021-06-10add ws support首次为 Midway 引入 WebSocket 框架能力Feature2.10.72021-04-17add event name args为事件绑定补充事件名参数Fix3.0.0-beta.72021-12-03middleware with ctx.body消息中间件支持ctx.body交互Fix3.0.0-beta.142022-01-04update dependency ws to v8底层 ws 库升级至 v8 大版本Fix3.4.0-beta.72022-07-12support socket connection and message middleware连接与消息双通道中间件Feature3.6.02022-10-10add guard引入守卫机制Feature3.7.02022-10-29纯版本号更新Note从这张表可以清晰看出midwayjs/ws的能力演进顺序先打通连接再补充事件参数随后完善中间件体系接着升级底层依赖到 ws v8最后引入守卫。值得注意的是CHANGELOG 在 2.10.x 及更早版本中混入了midwayjs/socketio的版本记录如 Version bump only for package midwayjs/socketio这反映了 monorepo 早期两包共用发布节奏的历史阅读时可留意区分。当前仓库中 package.json 显示的版本为4.2.3依赖ws8.21.0且声明了node 20的运行时要求——说明从 v3 一路走来的 ws v8 依赖策略延续至今。二、2.11.0WebSocket 支持是如何被引入 Midway 的CHANGELOG 最早的重大功能条目是 2.11.0 的 add ws supportissue #1058。它标志着 Midway 正式具备了原生 WebSocket 场景能力与 koa、express、egg 等传统 Web 场景并列。从 index.ts 的导出结构可以确认组件形态export { MidwayWSFramework as Framework } from ./framework; export * from ./interface; export { WebSocketConfiguration as Configuration } from ./configuration;组件由三部分组成MidwayWSFramework框架主体被Framework()装饰器标注、WebSocketConfiguration组件配置声明namespace: webSocket、以及对外暴露的类型定义。这意味着在业务侧只需在src/configuration.ts中通过imports引入midwayjs/ws框架层就会自动扫描注册的 WS 控制器并挂载 WebSocket 服务。与 HTTP 服务器共享端口的设计在 framework.ts 的run()方法中可以看到一个关键设计决策WebSocket 服务并不总是独立端口而是优先复用 HTTP 服务器if (!this.configurationOptions.port) { server this.applicationContext.get(HTTP_SERVER_KEY); this.logger.info([midway:ws] WebSocket server find shared http server and will be attach.); } else { server this.configurationOptions.server ?? http.createServer(); }即配置了port则自建 HTTP server 独立监听未配置port则从容器中取出 koa/express 等已启动的 HTTP server在其上监听upgrade事件完成 WebSocket 握手。这正是测试夹具 base-app/src/configuration.ts 中显式配置port: 3000的原因——独立端口便于单测环境启动。noServer: true与手动握手组件初始化时applicationInitialize强制noServer true不依赖 ws 库自动监听而是自行接管握手流程。随后框架通过loadMidwayController()读取WS_CONTROLLER_KEY元数据注册的控制器并绑定connection事件这一阶段已经能支撑基础的连接、收发、断开流程。三、3.4.0-beta.7连接中间件与消息中间件的双层体系如果说 2.11.0 打通了能用3.4.0-beta.7 的 support socket connection and message middlewareissue #1984则让midwayjs/ws进入好用阶段。它引入了两条独立的中间件通道连接中间件connection middleware作用于连接建立阶段在事件处理器运行前执行适合做连接级鉴权、日志、初始化消息中间件message middleware作用于每条消息处理链路与 koa 风格的洋葱模型一致适合做消息解析、校验、透传。连接中间件的注册与执行框架在 applicationInitialize 中向应用对象注入了三个扩展方法useConnectionMiddleware、getConnectionMiddleware、onWebSocketUpgrade。其中连接中间件通过独立的connectionMiddlewareManager管理framework.tspublic useConnectionMiddleware(middleware) { this.connectionMiddlewareManager.insertLast(middleware); }在每次新连接到达时addNamespace 内框架将全局连接中间件 控制器级连接中间件合并通过middlewareService.compose组装后执行并且整个连接回调被包在traceService.runWithEntrySpan(ws.connect ...)中自动生成ws.connect链路追踪 Span。消息中间件与事件绑定消息处理走的是另一条链路framework.ts框架根据控制器上OnWSMessage(eventName)元数据用socket.on(messageEventName, handler)绑定监听处理器内部再组合控制器级中间件 事件级中间件 目标方法同样以compose方式串行执行并用ws.message ${eventName}作为追踪 Span 名。值得注意的一个兼容细节处理器根据消息最后一个参数是否为函数自动区分ack 回调最后参数是函数则直接回传结果供客户端做请求-响应式通信与emit 广播否则走响应分发逻辑。这与 2.10.7 中 add event name args 修复一脉相承——事件处理器可以拿到完整的事件名参数。四、3.6.0守卫Guard如何参与 WebSocket 调用链3.6.0 的 add guardissue #2345把 Midway 3.x 的守卫机制带入了 WebSocket 场景。在连接事件处理中framework.ts事件处理器被组装时会在目标方法前插入守卫检查const isPassed await this.app.getFramework().runGuard(ctx, target, wsEventInfo.propertyName); if (!isPassed) { throw new MidwayInvokeForbiddenError(wsEventInfo.propertyName, target); }守卫通过runGuard统一执行失败时抛出MidwayInvokeForbiddenError中断调用。这使鉴权逻辑可以从中间件中剥离以声明式守卫的形式复用同一套规则与 HTTP 场景保持一致的心智模型。升级前鉴权握手阶段的另一道防线除了连接事件内的守卫框架还提供握手阶段的onWebSocketUpgrade钩子framework.ts 与接口定义 interface.tsexport type UpgradeAuthHandler ( request: IncomingMessage, socket: any, head: Buffer ) Promiseboolean;在server.on(upgrade)回调中framework.ts若设置了该 handler则先执行鉴权返回false或抛出异常时直接socket.destroy()拒绝握手通过后才调用this.app.handleUpgrade完成协议升级并发出connection事件。这样便形成了握手鉴权拦截未授权连接 守卫控制事件执行的双层安全模型。五、底层依赖演进ws 库从 v7 到 v8 的升级之路CHANGELOG 中占比最大的实质变更类型是依赖升级全部指向同一个库——ws版本升级目标3.0.0-beta.14ws v8大版本升级#14883.0.1ws v8.4.23.0.4ws v8.5.03.4.0-beta.10ws v8.8.13.5.3ws v8.9.0midwayjs/ws直接构建在ws库之上WebSocket.Server、socket.ping/pong、terminate、readyState等均为底层 API见 framework.ts 的import * as WebSocket from ws。升级到 v8 意味着框架可以获得更严格的消息处理、更好的性能与更完整的类型定义。当前仓库 package.json 已将ws锁定在8.21.0并配套types/ws8.5.14提供 TypeScript 类型支持——在阅读历史版本时若遇到与底层握手或心跳相关的问题可优先对照当时代入的 ws 版本行为差异。六、源码级原理midwayjs/ws的核心运行时机制综合 framework.ts 全文可以将组件运行时拆解为五个环节初始化applicationInitialize创建WebSocket.Server({ noServer: true })注入三个扩展方法扫描 WS 控制器握手run()内server.on(upgrade)可选升级鉴权 →handleUpgrade→ 触发connection连接上下文addNamespace的 connection 回调创建匿名请求上下文注册socket、request、app到请求级容器socket.requestContext使控制器内Inject() ctx可注入IMidwayWSContext事件绑定按WS_EVENT_KEY元数据遍历将OnWSConnection/OnWSMessage/OnWSDisConnection分别映射到connection、自定义消息事件、close响应分发bindSocketResponse处理器返回值根据事件元数据决定去向——EMIT回发当前连接、BROADCAST遍历app.clients中所有readyState WebSocket.OPEN的连接广播均通过runWithExitSpan(ws.emit ...)打点追踪没有WSBroadcast/WSEmit装饰器时默认直接回发本连接。响应格式统一经过formatResultframework.ts对象类型自动JSON.stringify其余原样发送——这正是测试中客户端收到{name:harry,result:6}JSON 字符串的原因。七、配置项详解来自 configuration.ts 与 interface.ts 的权威参数组件默认配置定义在 configuration.tsConfiguration({ namespace: webSocket, importConfigs: [{ default: { webSocket: { enableServerHeartbeatCheck: false, serverHeartbeatInterval: 30000, }, midwayLogger: { clients: { wsLogger: { fileLogName: midway-ws.log }, }, }, }, }], }) export class WebSocketConfiguration {}完整可配置项见 interface.ts 的IMidwayWSConfigurationOptions配置项默认值说明enableServerHeartbeatCheckfalse是否启用服务端心跳检测serverHeartbeatInterval30000心跳检测间隔毫秒port无指定端口时独立监听缺省时复用 HTTP serverserver无自定义 HTTP server 实例pubClient/subClient无预留的发布/订阅客户端广播扩展其余ws.ServerOptions—透传给底层WebSocket.Server如maxPayload等心跳机制在 startHeartBeat 中实现周期性遍历所有连接若某连接isAlive false则terminate()清理否则置为false并发送ping()客户端回pong时connection 回调内socket.on(pong)恢复isAlive true。测试夹具 base-app-heartbeat/src/configuration.ts 将间隔设为1000ms 以加速验证。八、实战用 midwayjs/ws 编写一个 WS 控制器以仓库测试夹具 api.ts 为例一个完整的 WS 控制器长这样import { Inject, OnWSConnection, OnWSDisConnection, OnWSMessage, Provide, WSController } from midwayjs/core; import { IMidwayWSContext } from midwayjs/ws; Provide() WSController() export class APIController { Inject() ctx: IMidwayWSContext; Inject() userService: UserService; OnWSConnection() init(socket, request) { // 连接建立时触发可拿到 socket 与 HTTP 握手请求 } OnWSMessage(message) async gotMyMessage(data) { // 收到 message 事件返回值自动回发可配合 WSEmit / WSBroadcast 控制分发 return { name: harry, result: parseInt(data) 5 }; } OnWSDisConnection() disconnect(id: number) { // 连接断开时触发 } }配套的 index.test.ts 验证了三类行为客户端发送1收到{name:harry,result:6}消息回发base-app-broadcast夹具下两个客户端同时收到广播total 12即 66 双端累加base-app-filter夹具验证中间件可将消息拦截改写为packet error心跳测试则确认客户端能收到ping帧。这些测试全部通过midwayjs/mock的createWebSocketClient与createLightApp在纯 Node 环境运行不需要真实浏览器。九、小结从 CHANGELOG 读懂组件的成熟路径回看 CHANGELOG.mdmidwayjs/ws的演进是一套典型的基础设施逐步完善路径先接入2.11.0→ 补齐事件参数2.10.7→ 升级底层 ws v83.0.0-beta.14→ 完善中间件3.4.0-beta.7→ 引入守卫3.6.0期间伴随多次依赖修补与 monorepo 版本同步。对于正在使用或计划引入midwayjs/ws的开发者本文梳理的配置参数、控制器范式、双层中间件与双层鉴权模型可直接映射到 framework.ts 与 interface.ts 的源码中进行二次确认做到文档有据、源码可查。赞分享后端微服务云原生【免费下载链接】midway A Node.js Serverless Framework for front-end/full-stack developers. Build the application for next decade. Works on AWS, Alibaba Cloud, Tencent Cloud and traditional VM/Container. Super easy integrate with React and Vue. 项目地址https://gitcode.com/gh_mirrors/mi/midway点击查看免费下载相关推荐Midway 安全组件 midwayjs/security 全解析从演进历史到配置实战Midway 安全组件 midwayjs/security 全解析从演进历史到配置实战 midwayjs/security 是 Midway 框架内置的通后端微服务云原生Midway gRPC 组件能力演进全解析从框架引入到 Stream API 与 Guard 支持Midway gRPC 组件能力演进全解析从框架引入到 Stream API 与 Guard 支持 导读 本文以 packages/grpc/CHANGELO后端微服务云原生Midway 核心包演进全解析从 midwayjs/core 的变更日志看 IoC 容器与 Web 框架的架构变迁Midway 核心包演进全解析从 midwayjs/core 的变更日志看 IoC 容器与 Web 框架的架构变迁 导读 packages/core/CHA后端微服务云原生上一篇TiXL 交互 Gizmo 指南在输出视口中直接拖拽操控三维对象下一篇FF14钓鱼计时器「渔人的直感」使用教程从错过鱼王到轻松收杆创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
