伴伴app实战：3种后端架构完整示例对比，别再死磕语法了
学会语法却不知怎么搭项目，这是很多开发者卡在“入门”与“实战”之间最难受的阶段。你背熟了 for 循环，记住了 class 定义，甚至能默写 async/await 的用法，但一旦要接一个像“伴伴app”这样包含实时聊天、用户状态同步、文件上传的完整业务，脑子就是一片空白。
今天不讲虚的，直接上干货。我们以“伴伴app”这个典型的社交+内容社区场景为靶子，横向对比 Go + Gin、Java + Spring Boot 和 Node.js + NestJS 三种主流后端方案。重点不是堆砌API，而是通过 完整示例 展示它们在处理核心业务（如WebSocket消息推送、并发控制、状态管理）时的底层差异和代码写法。
1. 各自定位：为什么选它？
在动手写代码前，先搞清楚这三种技术栈在“伴伴app”这种C端高并发、强实时场景下的定位。
Go + Gin 的核心理念是“简单即高效”。Go语言天生为并发而生，Goroutine的轻量级线程模型让它在处理成千上万个WebSocket连接时，内存占用极低。Gin框架作为目前Go生态最流行的Web框架，中间件机制完善，启动速度极快。对于“伴伴app”这种需要长期保持长连接、对延迟敏感的场景，Go是性能导向的首选。它适合追求极致吞吐量、团队具备一定系统编程基础、对资源成本敏感的团队。
Java + Spring Boot 则是企业级应用的“默认选项”。它的优势在于生态极其庞大，从ORM（MyBatis-Plus）、缓存（Redis）到消息队列（Kafka），几乎都有现成的、经过大规模生产验证的集成方案。Spring的依赖注入和事务管理非常成熟。对于“伴伴app”中涉及复杂的用户体系、支付流程、内容审核等重业务逻辑模块，Spring Boot能提供很强的稳定性和可维护性。它的缺点是内存占用高，启动慢，但在JVM优化得当的情况下，单机性能足以应对大部分中型流量。
Node.js + NestJS 代表了前后端同构的趋势。NestJS是一个基于Node.js的Angular风格框架，它引入了模块化、依赖注入和装饰器，让JavaScript代码具备了类似TypeScript或Java的结构化特征。对于“伴伴app”这种前端重度依赖React/Vue的项目，使用Node.js后端可以共享TypeScript类型定义，减少前后端联调成本。它的I/O模型与Go类似，适合I/O密集型任务，但在CPU密集型计算（如复杂图片处理）上不如Go和Java。
2. 核心差异：一张表看懂优劣
为了更直观地对比，我们针对“伴伴app”的核心需求维度进行打分和对比：维度
Go + Gin
Java + Spring Boot
Node.js + NestJS并发模型
Goroutine (轻量级线程)
线程池 (OS线程)
Event Loop (单线程非阻塞)内存占用
低 (单实例 ~20MB)
高 (单实例 ~200MB+)
中 (单实例 ~50MB)启动速度
极快 (100ms)
慢 (1-3秒)
快 (200ms)实时通信
原生支持，性能极佳
需引入WebSocket库，稍显笨重
原生支持，生态丰富开发效率
中等 (需处理错误返回)
高 (注解驱动，配置繁琐)
高 (TS类型安全，前后端同构)适用场景
高并发网关、微服务核心
复杂业务逻辑、金融级事务
实时聊天、API网关、全栈项目学习曲线
中等 (需理解GC和并发)
陡峭 (Spring全家桶)
平缓 (若熟悉JS/TS)从上表可以看出，没有绝对的“最好”，只有“最适合”。如果“伴伴app”日活百万，并发连接数高，Go的优势会非常明显；如果业务逻辑极其复杂，涉及多方对接和严格的事务一致性，Java更稳妥；如果团队规模小，希望前后端统一技术栈，NestJS是极佳选择。
3. 代码写法对比：完整示例解析
下面我们以“伴伴app”中一个核心功能——“用户发送消息并广播给在线好友” 为例，分别展示三种技术栈的 完整示例 代码片段。注意，这里为了篇幅精简，省略了数据库连接和认证中间件，聚焦于核心业务逻辑的处理方式。
3.1 Go + Gin 实现
Go的特点是显式的错误处理和简洁的并发原语。在处理WebSocket消息时，我们通常使用 Goroutine 来处理每个连接，利用 Channel 或 Sync.Map 来管理在线用户状态。
package mainimport (fmtnet/httpsyncgithub.com/gin-gonic/gingithub.com/gorilla/websocket
)var upgrader = websocket.Upgrader{CheckOrigin: func(r *http.Request) bool { return true },
}type User struct {ID stringConn *websocket.Conn
}var onlineUsers = make(map[string]*User)
var mu sync.Mutexfunc handleWebSocket(c *gin.Context) {conn, err := upgrader.Upgrade(c.Writer, c.Request, nil)if err != nil {return}defer conn.Close()// 模拟获取用户IDuserID := user_1001u := User{ID: userID, Conn: conn}mu.Lock()onlineUsers[userID] = umu.Unlock()for {_, message, err := conn.ReadMessage()if err != nil {break}// 广播给所有在线用户（实际生产中应只广播给特定好友）broadcastMessage(userID, string(message))}mu.Lock()delete(onlineUsers, userID)mu.Unlock()
}func broadcastMessage(senderID, msg string) {mu.Lock()defer mu.Unlock()for id, user := range onlineUsers {if id != senderID {err := user.Conn.WriteMessage(websocket.TextMessage, []byte(msg))if err != nil {fmt.Printf(Error sending message to %s: %v\n, id, err)}}}
}func main() {r := gin.Default()r.GET(/ws, handleWebSocket)r.Run(:8080)
}解析：并发安全： 使用 sync.Mutex 保护 onlineUsers 这个全局Map，这是Go中常见的并发控制模式。
资源管理： defer conn.Close() 确保连接在函数退出时自动关闭，避免资源泄露。
性能优势： 每个WebSocket连接对应一个Goroutine，开销极小。即使有10万连接，内存占用也远低于Java。3.2 Java + Spring Boot 实现
Java生态中，通常使用 Spring WebSocket 或 Netty 来实现高性能WebSocket。这里我们展示一个基于Spring Boot的简化版实现，重点在于其注解驱动和依赖注入的特性。
import org.springframework.stereotype.Component;
import org.springframework.web.socket.TextMessage;
import org.springframework.web.socket.WebSocketSession;
import org.springframework.web.socket.handler.TextWebSocketHandler;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;@Component
public class ChatWebSocketHandler extends TextWebSocketHandler {// 线程安全的Map，用于存储在线用户private static final MapString, WebSocketSession onlineUsers = new ConcurrentHashMap();@Overridepublic void afterConnectionEstablished(WebSocketSession session) throws Exception {// 模拟获取用户IDString userId = user_1001;onlineUsers.put(userId, session);System.out.println(User + userId + connected);}@Overrideprotected void handleTextMessage(WebSocketSession session, TextMessage message) throws Exception {String msg = message.getPayload();String senderId = user_1001;// 广播给所有在线用户for (Map.EntryString, WebSocketSession entry : onlineUsers.entrySet()) {if (!entry.getKey().equals(senderId)) {entry.getValue().sendMessage(new TextMessage(msg));}}}@Overridepublic void afterConnectionClosed(WebSocketSession session, org.springframework.web.socket.CloseStatus status) throws Exception {String userId = user_1001;onlineUsers.remove(userId);System.out.println(User + userId + disconnected);}
}// 配置类（需单独定义WebSocketConfig类进行注册）解析：线程安全： 使用 ConcurrentHashMap，这是Java并发包中专门为高并发场景设计的Map，比Go的手动加锁更直观。
生命周期管理： Spring容器管理Bean的生命周期，afterConnectionEstablished 和 afterConnectionClosed 是标准的回调方法，代码结构清晰。
集成能力： 在实际项目中，这个Handler可以轻松注入 UserService 或 RedisTemplate，实现复杂的好友关系查询，这是Spring生态的优势。3.3 Node.js + NestJS 实现
NestJS使用装饰器（Decorators）来标记类和函数，代码风格非常接近Java和TypeScript。对于实时通信，NestJS提供了 @WebSocketGateway 装饰器。
import { WebSocketGateway, WebSocketServer, SubscribeMessage, OnGatewayConnection, OnGatewayDisconnect } from '@nestjs/websockets';
import { Server } from 'socket.io';@WebSocketGateway()
export class ChatGateway implements OnGatewayConnection, OnGatewayDisconnect {@WebSocketServer()server: Server;handleConnection(client: any) {// 模拟获取用户IDconst userId = 'user_1001';client.data.userId = userId;console.log(`User ${userId} connected`);}handleDisconnect(client: any) {const userId = client.data.userId;console.log(`User ${userId} disconnected`);}@SubscribeMessage('message')handleMessage(client: any, payload: string): { event: string; data: string } {const senderId = client.data.userId;// 广播给所有其他客户端this.server.emit('broadcast', {event: 'message',data: `${senderId}: ${payload}`});return { event: 'message', data: 'ok' };}
}解析：类型安全： 如果使用TypeScript编写，client 和 payload 都有明确的类型定义，IDE提示极其友好。
装饰器语法： @SubscribeMessage('message') 将HTTP事件与处理方法绑定，代码非常简洁，无需像Go那样手动解析WebSocket帧。
Socket.IO集成： NestJS深度集成了Socket.IO，emit 方法可以直接广播，底层处理了心跳、重连等复杂逻辑，开发体验极佳。4. 适用场景：对号入座
选型的本质是匹配业务特征与团队能力。
选 Go + Gin，如果：“伴伴app”的瓶颈在于网络I/O和并发连接数，比如用户经常在线，消息推送频繁。
团队希望降低服务器成本，追求高资源利用率。
团队中有资深后端，熟悉C/C++或Go语言，能接受手动管理错误和并发。
需要极高的启动速度，用于Serverless或Kubernetes中的快速扩缩容。选 Java + Spring Boot，如果：业务逻辑非常复杂，涉及支付、订单、审核等多个微服务协作。
公司已有Java技术栈，团队对Spring生态熟悉，招聘容易。
对事务一致性和系统稳定性要求极高，需要成熟的监控和日志体系。
流量不是极端高并发（如千万级同时在线），中等并发下JVM性能足够。选 Node.js + NestJS，如果：团队是全栈团队，前端主要用React/Vue + TypeScript，希望前后端代码风格统一。
项目迭代速度极快，需要快速原型开发。
业务以I/O密集型为主（如聊天、通知、内容展示），CPU计算任务较少。
希望利用NestJS的模块化结构，解决传统Node.js项目“面条代码”的问题。5. 选型建议：避坑指南
在实际落地“伴伴app”这类项目时，有几个常见的坑需要避开：不要为了性能牺牲可维护性： 很多新人喜欢用Go，因为跑分高。但如果团队没有Go的经验，用Go写复杂的业务逻辑（如复杂的权限校验、多表关联查询）会非常痛苦，错误处理繁琐。这种情况下，Java或Node.js可能是更好的选择。
WebSocket不是银弹： 无论选哪种技术，WebSocket长连接都需要处理心跳检测、断线重连、消息持久化。Go需要自己写逻辑，Node.js有Socket.IO库支持，Java需要配置心跳策略。务必在选型时评估这部分的工作量。
RFC 规范的重要性： 在实现WebSocket协议时，务必遵循 RFC 6455 规范。比如，浏览器端WebSocket握手必须使用 Upgrade: websocket 头部，服务器必须返回 101 Switching Protocols。很多自定义网关或负载均衡器如果不支持WebSocket升级，会导致连接直接断开。在选型前，先确认你的基础设施（Nginx、ALB）是否支持WebSocket透传，这比选什么语言更重要。
混合架构是常态： 大型“伴伴app”往往是混合架构。例如，用 Go 做高并发的消息网关（Gateway），负责维持WebSocket连接；用 Java 做核心业务服务（UserService, OrderService），负责复杂逻辑和数据库操作；用 Node.js 做内容聚合API或前端BFF层。不要迷信单一技术栈，按职责拆分才是王道。结语
技术选型没有标准答案，只有最适合当下的解。对于“伴伴app”这种项目，建议先梳理核心业务链路，评估并发量级和团队技术栈，再决定是用Go的极致性能，Java的稳健生态，还是Node.js的开发效率。
别忘了，代码只是表象，架构设计才是灵魂。在动手写第一个 Hello World 之前，先画好时序图，想清楚数据流向，这样才能避免后期重构的痛苦。
还有什么不懂的？比如具体如何配置Nginx透传WebSocket，或者Go中如何优雅地处理Context取消？评论区留言，挨个回。 伴伴app实战：3种后端架构完整示例对比，别再死磕语法了
伴伴app实战：3种后端架构完整示例对比，别再死磕语法了
学会语法却不知怎么搭项目，这是很多开发者卡在“入门”与“实战”之间最难受的阶段。你背熟了 for 循环，记住了 class 定义，甚至能默写 async/await 的用法，但一旦要接一个像“伴伴app”这样包含实时聊天、用户状态同步、文件上传的完整业务，脑子就是一片空白。
今天不讲虚的，直接上干货。我们以“伴伴app”这个典型的社交+内容社区场景为靶子，横向对比 Go + Gin、Java + Spring Boot 和 Node.js + NestJS 三种主流后端方案。重点不是堆砌API，而是通过 完整示例 展示它们在处理核心业务（如WebSocket消息推送、并发控制、状态管理）时的底层差异和代码写法。
1. 各自定位：为什么选它？
在动手写代码前，先搞清楚这三种技术栈在“伴伴app”这种C端高并发、强实时场景下的定位。
Go + Gin 的核心理念是“简单即高效”。Go语言天生为并发而生，Goroutine的轻量级线程模型让它在处理成千上万个WebSocket连接时，内存占用极低。Gin框架作为目前Go生态最流行的Web框架，中间件机制完善，启动速度极快。对于“伴伴app”这种需要长期保持长连接、对延迟敏感的场景，Go是性能导向的首选。它适合追求极致吞吐量、团队具备一定系统编程基础、对资源成本敏感的团队。
Java + Spring Boot 则是企业级应用的“默认选项”。它的优势在于生态极其庞大，从ORM（MyBatis-Plus）、缓存（Redis）到消息队列（Kafka），几乎都有现成的、经过大规模生产验证的集成方案。Spring的依赖注入和事务管理非常成熟。对于“伴伴app”中涉及复杂的用户体系、支付流程、内容审核等重业务逻辑模块，Spring Boot能提供很强的稳定性和可维护性。它的缺点是内存占用高，启动慢，但在JVM优化得当的情况下，单机性能足以应对大部分中型流量。
Node.js + NestJS 代表了前后端同构的趋势。NestJS是一个基于Node.js的Angular风格框架，它引入了模块化、依赖注入和装饰器，让JavaScript代码具备了类似TypeScript或Java的结构化特征。对于“伴伴app”这种前端重度依赖React/Vue的项目，使用Node.js后端可以共享TypeScript类型定义，减少前后端联调成本。它的I/O模型与Go类似，适合I/O密集型任务，但在CPU密集型计算（如复杂图片处理）上不如Go和Java。
2. 核心差异：一张表看懂优劣
为了更直观地对比，我们针对“伴伴app”的核心需求维度进行打分和对比：维度
Go + Gin
Java + Spring Boot
Node.js + NestJS并发模型
Goroutine (轻量级线程)
线程池 (OS线程)
Event Loop (单线程非阻塞)内存占用
低 (单实例 ~20MB)
高 (单实例 ~200MB+)
中 (单实例 ~50MB)启动速度
极快 (100ms)
慢 (1-3秒)
快 (200ms)实时通信
原生支持，性能极佳
需引入WebSocket库，稍显笨重
原生支持，生态丰富开发效率
中等 (需处理错误返回)
高 (注解驱动，配置繁琐)
高 (TS类型安全，前后端同构)适用场景
高并发网关、微服务核心
复杂业务逻辑、金融级事务
实时聊天、API网关、全栈项目学习曲线
中等 (需理解GC和并发)
陡峭 (Spring全家桶)
平缓 (若熟悉JS/TS)从上表可以看出，没有绝对的“最好”，只有“最适合”。如果“伴伴app”日活百万，并发连接数高，Go的优势会非常明显；如果业务逻辑极其复杂，涉及多方对接和严格的事务一致性，Java更稳妥；如果团队规模小，希望前后端统一技术栈，NestJS是极佳选择。
3. 代码写法对比：完整示例解析
下面我们以“伴伴app”中一个核心功能——“用户发送消息并广播给在线好友” 为例，分别展示三种技术栈的 完整示例 代码片段。注意，这里为了篇幅精简，省略了数据库连接和认证中间件，聚焦于核心业务逻辑的处理方式。
3.1 Go + Gin 实现
Go的特点是显式的错误处理和简洁的并发原语。在处理WebSocket消息时，我们通常使用 Goroutine 来处理每个连接，利用 Channel 或 Sync.Map 来管理在线用户状态。
package mainimport (fmtnet/httpsyncgithub.com/gin-gonic/gingithub.com/gorilla/websocket
)var upgrader = websocket.Upgrader{CheckOrigin: func(r *http.Request) bool { return true },
}type User struct {ID stringConn *websocket.Conn
}var onlineUsers = make(map[string]*User)
var mu sync.Mutexfunc handleWebSocket(c *gin.Context) {conn, err := upgrader.Upgrade(c.Writer, c.Request, nil)if err != nil {return}defer conn.Close()// 模拟获取用户IDuserID := user_1001u := User{ID: userID, Conn: conn}mu.Lock()onlineUsers[userID] = umu.Unlock()for {_, message, err := conn.ReadMessage()if err != nil {break}// 广播给所有在线用户（实际生产中应只广播给特定好友）broadcastMessage(userID, string(message))}mu.Lock()delete(onlineUsers, userID)mu.Unlock()
}func broadcastMessage(senderID, msg string) {mu.Lock()defer mu.Unlock()for id, user := range onlineUsers {if id != senderID {err := user.Conn.WriteMessage(websocket.TextMessage, []byte(msg))if err != nil {fmt.Printf(Error sending message to %s: %v\n, id, err)}}}
}func main() {r := gin.Default()r.GET(/ws, handleWebSocket)r.Run(:8080)
}解析：并发安全： 使用 sync.Mutex 保护 onlineUsers 这个全局Map，这是Go中常见的并发控制模式。
资源管理： defer conn.Close() 确保连接在函数退出时自动关闭，避免资源泄露。
性能优势： 每个WebSocket连接对应一个Goroutine，开销极小。即使有10万连接，内存占用也远低于Java。3.2 Java + Spring Boot 实现
Java生态中，通常使用 Spring WebSocket 或 Netty 来实现高性能WebSocket。这里我们展示一个基于Spring Boot的简化版实现，重点在于其注解驱动和依赖注入的特性。
import org.springframework.stereotype.Component;
import org.springframework.web.socket.TextMessage;
import org.springframework.web.socket.WebSocketSession;
import org.springframework.web.socket.handler.TextWebSocketHandler;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;@Component
public class ChatWebSocketHandler extends TextWebSocketHandler {// 线程安全的Map，用于存储在线用户private static final MapString, WebSocketSession onlineUsers = new ConcurrentHashMap();@Overridepublic void afterConnectionEstablished(WebSocketSession session) throws Exception {// 模拟获取用户IDString userId = user_1001;onlineUsers.put(userId, session);System.out.println(User + userId + connected);}@Overrideprotected void handleTextMessage(WebSocketSession session, TextMessage message) throws Exception {String msg = message.getPayload();String senderId = user_1001;// 广播给所有在线用户for (Map.EntryString, WebSocketSession entry : onlineUsers.entrySet()) {if (!entry.getKey().equals(senderId)) {entry.getValue().sendMessage(new TextMessage(msg));}}}@Overridepublic void afterConnectionClosed(WebSocketSession session, org.springframework.web.socket.CloseStatus status) throws Exception {String userId = user_1001;onlineUsers.remove(userId);System.out.println(User + userId + disconnected);}
}// 配置类（需单独定义WebSocketConfig类进行注册）解析：线程安全： 使用 ConcurrentHashMap，这是Java并发包中专门为高并发场景设计的Map，比Go的手动加锁更直观。
生命周期管理： Spring容器管理Bean的生命周期，afterConnectionEstablished 和 afterConnectionClosed 是标准的回调方法，代码结构清晰。
集成能力： 在实际项目中，这个Handler可以轻松注入 UserService 或 RedisTemplate，实现复杂的好友关系查询，这是Spring生态的优势。3.3 Node.js + NestJS 实现
NestJS使用装饰器（Decorators）来标记类和函数，代码风格非常接近Java和TypeScript。对于实时通信，NestJS提供了 @WebSocketGateway 装饰器。
import { WebSocketGateway, WebSocketServer, SubscribeMessage, OnGatewayConnection, OnGatewayDisconnect } from '@nestjs/websockets';
import { Server } from 'socket.io';@WebSocketGateway()
export class ChatGateway implements OnGatewayConnection, OnGatewayDisconnect {@WebSocketServer()server: Server;handleConnection(client: any) {// 模拟获取用户IDconst userId = 'user_1001';client.data.userId = userId;console.log(`User ${userId} connected`);}handleDisconnect(client: any) {const userId = client.data.userId;console.log(`User ${userId} disconnected`);}@SubscribeMessage('message')handleMessage(client: any, payload: string): { event: string; data: string } {const senderId = client.data.userId;// 广播给所有其他客户端this.server.emit('broadcast', {event: 'message',data: `${senderId}: ${payload}`});return { event: 'message', data: 'ok' };}
}解析：类型安全： 如果使用TypeScript编写，client 和 payload 都有明确的类型定义，IDE提示极其友好。
装饰器语法： @SubscribeMessage('message') 将HTTP事件与处理方法绑定，代码非常简洁，无需像Go那样手动解析WebSocket帧。
Socket.IO集成： NestJS深度集成了Socket.IO，emit 方法可以直接广播，底层处理了心跳、重连等复杂逻辑，开发体验极佳。4. 适用场景：对号入座
选型的本质是匹配业务特征与团队能力。
选 Go + Gin，如果：“伴伴app”的瓶颈在于网络I/O和并发连接数，比如用户经常在线，消息推送频繁。
团队希望降低服务器成本，追求高资源利用率。
团队中有资深后端，熟悉C/C++或Go语言，能接受手动管理错误和并发。
需要极高的启动速度，用于Serverless或Kubernetes中的快速扩缩容。选 Java + Spring Boot，如果：业务逻辑非常复杂，涉及支付、订单、审核等多个微服务协作。
公司已有Java技术栈，团队对Spring生态熟悉，招聘容易。
对事务一致性和系统稳定性要求极高，需要成熟的监控和日志体系。
流量不是极端高并发（如千万级同时在线），中等并发下JVM性能足够。选 Node.js + NestJS，如果：团队是全栈团队，前端主要用React/Vue + TypeScript，希望前后端代码风格统一。
项目迭代速度极快，需要快速原型开发。
业务以I/O密集型为主（如聊天、通知、内容展示），CPU计算任务较少。
希望利用NestJS的模块化结构，解决传统Node.js项目“面条代码”的问题。5. 选型建议：避坑指南
在实际落地“伴伴app”这类项目时，有几个常见的坑需要避开：不要为了性能牺牲可维护性： 很多新人喜欢用Go，因为跑分高。但如果团队没有Go的经验，用Go写复杂的业务逻辑（如复杂的权限校验、多表关联查询）会非常痛苦，错误处理繁琐。这种情况下，Java或Node.js可能是更好的选择。
WebSocket不是银弹： 无论选哪种技术，WebSocket长连接都需要处理心跳检测、断线重连、消息持久化。Go需要自己写逻辑，Node.js有Socket.IO库支持，Java需要配置心跳策略。务必在选型时评估这部分的工作量。
RFC 规范的重要性： 在实现WebSocket协议时，务必遵循 RFC 6455 规范。比如，浏览器端WebSocket握手必须使用 Upgrade: websocket 头部，服务器必须返回 101 Switching Protocols。很多自定义网关或负载均衡器如果不支持WebSocket升级，会导致连接直接断开。在选型前，先确认你的基础设施（Nginx、ALB）是否支持WebSocket透传，这比选什么语言更重要。
混合架构是常态： 大型“伴伴app”往往是混合架构。例如，用 Go 做高并发的消息网关（Gateway），负责维持WebSocket连接；用 Java 做核心业务服务（UserService, OrderService），负责复杂逻辑和数据库操作；用 Node.js 做内容聚合API或前端BFF层。不要迷信单一技术栈，按职责拆分才是王道。结语
技术选型没有标准答案，只有最适合当下的解。对于“伴伴app”这种项目，建议先梳理核心业务链路，评估并发量级和团队技术栈，再决定是用Go的极致性能，Java的稳健生态，还是Node.js的开发效率。
别忘了，代码只是表象，架构设计才是灵魂。在动手写第一个 Hello World 之前，先画好时序图，想清楚数据流向，这样才能避免后期重构的痛苦。
还有什么不懂的？比如具体如何配置Nginx透传WebSocket，或者Go中如何优雅地处理Context取消？评论区留言，挨个回。