★ FEATURED ARTICLE 简介面向Go语言初学者与网络编程入门者的局域网聊天程序源码包围绕控制台环境下的基础IM通信场景展开可用于理解服务端与客户端之间的连接建立、消息收发及并发处理流程。压缩包共6个文件以4个Go源码文件为主另含服务端与客户端相关文件整体约3.72MB体量轻便便于本地编译运行和分层阅读。目前已有222人学习下载适合作为课程实验、自学练手或小型局域网通信示例的起点。代码实现基础聊天功能结构较直观读者可据此梳理服务端监听、客户端接入、用户管理与消息转发等核心环节并在此基础上继续扩展私聊、群聊、昵称显示、在线列表或简单日志等功能形成从跑通到二次开发的实践路径。1. 从一台没有外网的教学机说起为什么要用 Go 写控制台局域网聊天程序机房断网、会议室没有外网、实验室几台机器只想互相发消息这类场景里用 Go 实现的局域网聊天程序比多数重型方案都省事编译出来是单文件双击就开既不依赖数据库也不需要浏览器。这套方案要做的是控制台下的多人群聊——自动发现同网段主机、输入昵称上线、广播消息、查看在线列表、异常掉线让其他人立刻看见。它适合拿来当网络编程课设或毕设的功能底座也适合内网临时沟通的小团队直接改。2. 通信模型与消息帧设计中心转发拓扑、四类报文与长度前缀协议动手写代码之前先把两件事定下来谁跟谁连以及一句话在网络里长什么样。这两件事决定后面 80% 的调试成本。很多同学上来就net.Dial然后conn.Write([]byte(hello))跑通一个 demo 没问题一旦加上昵称、上线通知、在线列表代码就开始打架最后只能推倒重来。稳妥的做法是先确定拓扑再确定帧最后才写业务逻辑。2.1 拓扑选型中心转发胜过全网状直连用局域网聊天程序直觉上最“公平”的设计是全网状 P2P每台机器都连其他所有机器谁都不当服务器。听着优雅实现起来会发现一堆麻烦。N 台机器需要 N(N-1)/2 条连接昵称变更要往每个对端同步一遍谁先上线谁后上线没有统一视图离线通知要靠各自超时判断消息顺序更是没法保证。聊天这种场景对延迟的要求其实很低局域网内多一跳转发不过多几毫秒完全感知不到。所以这套方案选中心转发一台机器跑 server其余跑 client所有消息经服务端中转。代价是需要一个人当主机得先启动服务端再让其他人加入。这个“代价”在课设答辩现场反而是优点——主机在谁手上、房间里有几个人、谁掉线了全在一个进程里你讲得清楚老师也看得明白。真要做得更花哨可以后面再加“客户端也能开房间”的选举逻辑但第一版不要碰。维度中心转发 C/S全网状 P2P连接数N 条每个客户端一条N(N-1)/2 条上线/下线通知服务端统一广播天然一致每个节点自行推断易不一致消息顺序服务端串行处理顺序稳定无全局顺序部署成本需先起一台服务端无中心但发现逻辑复杂故障定位看服务端一份日志即可要挨个节点排查适用规模几人到几十人三到五人的临时场景上表的结论很直接规模在几十人以内中心转发的实现成本和调试成本都低一个量级。真到了要横向扩展的体量那也不是控制台聊天程序该解决的问题了。2.2 消息帧格式4 字节长度前缀加 JSON 载荷TCP 是字节流没有消息边界。你在客户端Write一次服务端可能分两次Read读到也可能两次Write被一次Read全吞进去。用换行符分隔是最省事的做法但消息体里只要出现换行比如用户粘贴了一段代码解析立刻错位还得自己做转义。长度前缀没有这个毛病先读 4 字节拿到长度再按长度读满载荷天然对齐。载荷用 JSON理由是调试期可以直接fmt.Printf(%s, payload)看内容不用写二进制解析器。每帧的头部和载荷约定如下字段类型说明lengthuint324 字节大端后续 JSON 载荷的字节数不含自身typestringjoin / msg / list / quit / ping / sys 之一fromstring发送者昵称服务端转发时以服务端记录的为准不信任客户端自报tsint64Unix 毫秒时间戳用于客户端排序和排查bodystring消息正文join 时为昵称sys 时为系统提示const maxFrame 64 * 1024 // 单帧上限防止伪造的超大 length 把内存打爆 // ReadFrame 从连接里读出一个完整帧的载荷返回的 payload 已去掉 4 字节头 func ReadFrame(r io.Reader) ([]byte, error) { var hdr [4]byte // io.ReadFull 是关键它保证要么读满 4 字节要么返回错误不会出现半包头 if _, err : io.ReadFull(r, hdr[:]); err ! nil { return nil, err } n : binary.BigEndian.Uint32(hdr[:]) if n 0 || n maxFrame { return nil, fmt.Errorf(frame size %d out of range, n) } payload : make([]byte, n) if _, err : io.ReadFull(r, payload); err ! nil { return nil, err } return payload, nil } // WriteFrame 写帧服务端所有对外的写操作都必须走这里避免两处拼包 func WriteFrame(w io.Writer, payload []byte) error { if len(payload) maxFrame { return fmt.Errorf(payload too large: %d, len(payload)) } var hdr [4]byte binary.BigEndian.PutUint32(hdr[:], uint32(len(payload))) if _, err : w.Write(hdr[:]); err ! nil { return err } _, err : w.Write(payload) return err }几个参数值得单独说。maxFrame取 64KB 是权衡一条聊天消息撑死几百字节留 64KB 足够容纳未来可能的文件片段或长文本同时把恶意长度字段的破坏上限锁死在 64KB。大端序是网络字节序的惯例两边一致就行但别一边大端一边小端那是排查三天都未必能找到的坑。io.ReadFull必须用普通的Read返回n len(buf)时你无法判断是包没发完还是对面卡了加上 TCP 本身不保证一次读到完整数据用错这个函数就会出现“偶尔消息被截断”的玄学现象。提示帧长度字段本身不计入长度值这是最容易写反的一处。定好规则后在 protocol 包里写一个 round-trip 单测比联调时盯着日志猜要快得多。2.3 模块划分与目录结构代码按“协议 / 服务端 / 客户端 / 发现”四块切每块一个 internal 包主程序只负责装配。这样切的好处是写单元测试时不用起真连接协议层的编解码可以脱离网络单独验证。lanchat/ ├── cmd/ │ ├── server/main.go # 服务端入口解析 -addr 参数后装配 Hub │ └── client/main.go # 客户端入口处理昵称输入与界面循环 ├── internal/ │ ├── protocol/ │ │ ├── frame.go # ReadFrame / WriteFrame │ │ └── message.go # Message 结构体与 NewMsg 构造函数 │ ├── server/ │ │ ├── hub.go # 连接注册、广播、踢人 │ │ └── room.go # 在线列表快照 │ ├── client/ │ │ ├── ui.go # 打印锁、提示符重绘、颜色 │ │ └── command.go # /list /nick /quit 解析 │ └── discovery/ │ └── udp.go # UDP 广播探测与应答 └── go.modinternal/protocol不认识网络连接只认io.Reader和io.Writer这是刻意设计的给它传bytes.Buffer就能测编解码传net.Conn就是生产路径。internal/server里的 Hub 持有全部连接状态是这个程序里唯一需要加锁的地方其他包保持无共享状态。internal/client/ui.go单独抽出来是因为控制台输出和输入打架的问题最后一定会花掉你半天时间把它关进一个文件里改起来只改一处。3. 服务端核心实现连接注册、广播中心与慢客户端隔离服务端要管的事情看着不多收连接、记昵称、转发消息、掉线清理。真正难的是并发下的状态一致性以及一个不吭声的客户端怎么不拖累其他人。这一章按接入、广播、下线三个阶段把 Hub 写完。3.1 连接接入与昵称注册第一条报文必须是 joinAccept之后立刻起一个 goroutine 处理这条连接主循环不能阻塞在任何一个客户端身上。新连接进来的第一件事不是读消息而是等它的join帧拿到昵称后校验长度1 到 16 个字符去掉首尾空白检查重名重名就自动加后缀而不是直接拒绝——答辩现场两个同学都叫“test”的概率比你想象的高直接踢人会让演示很尴尬。func (h *Hub) handleConn(conn net.Conn) { defer conn.Close() // 注册阶段给 10 秒窗口避免半开连接一直占着 goroutine _ conn.SetReadDeadline(time.Now().Add(10 * time.Second)) payload, err : protocol.ReadFrame(conn) if err ! nil { return } var m protocol.Message if err : json.Unmarshal(payload, m); err ! nil || m.Type ! join { return } name : h.uniqueName(strings.TrimSpace(m.Body)) if name { return } c : Client{conn: conn, name: name, send: make(chan []byte, 64)} h.register(c) // 加锁写入 clients然后广播 sys xxx 加入了 go c.writeLoop() // 独立的写协程见 3.2 c.readLoop(h) // 当前协程负责读 } // uniqueName 处理重名张三、张三(2)、张三(3)…… func (h *Hub) uniqueName(base string) string { h.mu.Lock() defer h.mu.Unlock() if _, ok : h.names[base]; !ok { h.names[base] struct{}{} return base } for i : 2; i 100; i { cand : fmt.Sprintf(%s(%d), base, i) if _, ok : h.names[cand]; !ok { h.names[cand] struct{}{} return cand } } return }读超时只在注册阶段设置注册成功后必须清掉否则十分钟后所有正常用户会被自己的超时踢下线。这个 bug 的典型表现是“聊着聊着所有人同时掉线”第一次遇到很容易怀疑网络。3.2 广播中心用 channel 收口所有写操作服务端最忌讳的写法是在持有锁的情况下直接conn.Write。写操作可能阻塞对端缓冲区满、对方笔记本休眠、网线被拔一旦阻塞发生在锁内整个房间的消息全部卡住表现就是“某个人一掉线所有人都停顿十几秒”。正确做法是每个客户端配一个带缓冲的发送 channel广播只负责往 channel 里塞真正的写发生在各自的写协程里。// broadcast 把同一份 payload 投递给所有在线客户端永不阻塞调用方 func (h *Hub) broadcast(payload []byte) { h.mu.RLock() targets : make([]*Client, 0, len(h.clients)) for c : range h.clients { targets append(targets, c) } h.mu.RUnlock() // 先复制一份快照再释放读锁后面的发送不占锁 for _, c : range targets { select { case c.send - payload: default: // 缓冲满了说明这个客户端消费不过来踢掉别让其他人陪着等 h.kick(c, send buffer full) } } } func (c *Client) writeLoop() { ping : time.NewTicker(20 * time.Second) defer ping.Stop() for { select { case payload, ok : -c.send: if !ok { return } c.conn.SetWriteDeadline(time.Now().Add(5 * time.Second)) if err : protocol.WriteFrame(c.conn, payload); err ! nil { c.close() return } case -ping.C: // 心跳兼做保活客户端长时间收不到就会主动重连 if err : protocol.WriteFrame(c.conn, protocol.MustJSON(protocol.Message{ Type: ping, TS: time.Now().UnixMilli(), })); err ! nil { c.close() return } } } }这里有两个数字值得推敲。发送缓冲取 64意味着一个客户端最多落后 64 条消息正常打字速度下相当于落后几十秒够用了取太小会误踢正常用户取太大则内存占用上升且掉线感知变慢。写超时 5 秒是给跨交换机、无线网络留的余量超时就判死代价是这个用户丢一条消息收益是整个房间不卡。心跳 20 秒一次比多数防火墙的 UDP/TCP 空闲回收时间短能避免连接被中间设备静默切断。注意kick里必须用sync.Once保护关闭动作。广播循环里可能对同一个客户端连续两次判定失败如果没有幂等保护close(c.send)会 panic整个服务端进程直接退出。3.3 心跳、超时与优雅下线下线有三条路径客户端主动发quit、读协程返回错误、被kick。三条路径最后都汇到同一个unregister保证在线列表、昵称表、广播通知三件事要么一起发生要么都不发生。func (h *Hub) unregister(c *Client) { h.mu.Lock() if _, ok : h.clients[c]; !ok { h.mu.Unlock() return // 已经清理过直接返回保证幂等 } delete(h.clients, c) delete(h.names, c.name) h.mu.Unlock() c.close() // 关闭 send channel写协程收到零值后自然退出 h.broadcast(protocol.MustJSON(protocol.Message{ Type: sys, TS: time.Now().UnixMilli(), Body: c.name 离开了房间, })) }读协程里要区分错误类型io.EOF和对端 reset 属于正常掉线安静清理就行帧长度越界属于异常应该记一条日志再断开方便排查是不是客户端版本不一致。在线列表用list请求即时生成快照返回别缓存几十人的规模实时算一遍开销可以忽略缓存反而引入一致性问题。4. 客户端实现双 goroutine 分离输入输出与命令解析客户端的难点不在网络而在终端。os.Stdin的读取是阻塞的你又必须同时接收服务端推来的消息——只用主协程顺序执行的话用户不敲回车别人发的消息就永远显示不出来。解法是把输入和接收拆成两个 goroutine再配一把打印锁。4.1 输入与接收分离两个 goroutine 加一把打印锁接收协程负责ReadFrame然后打印输入协程用bufio.Scanner逐行读os.Stdin然后发送。两者都会写屏幕必须互斥否则中文输出会交错成乱码。更进一步用户正在输入到一半时被一条新消息顶掉行会断在中间体验很差。常规处理是打印前用\r\033[K把当前行清掉打印完消息再重绘提示符和用户已输入的内容。type UI struct { mu sync.Mutex buf []byte // 记录用户当前已输入但未提交的字符用于重绘 prompt string } func (u *UI) Println(line string) { u.mu.Lock() defer u.mu.Unlock() fmt.Print(\r\033[K) // 回到行首并清空整行抹掉半截输入 fmt.Println(line) fmt.Print(u.prompt string(u.buf)) // 重绘提示符和残余输入 } func (u *UI) ReadLine(sc *bufio.Scanner) (string, bool) { u.mu.Lock() u.buf u.buf[:0] u.mu.Unlock() if !sc.Scan() { return , false } u.mu.Lock() u.buf u.buf[:0] // 提交后清空避免下次重绘出旧内容 u.mu.Unlock() return sc.Text(), true }\033[K是 ANSI 清行序列Windows 10 之后的默认终端支持老系统上会打印出方框那时候退化成直接换行输出就行别在这上面死磕。提示符统一存成[昵称]昵称变了同步更新重绘才不会出错。接收协程还需要处理一个细节收到ping不要打印只更新本地最后活跃时间连续 60 秒没收到任何帧就认为服务端没了主动退出并提示。这个判断放在客户端比放服务端更合理因为服务端进程被杀时来不及通知任何人。4.2 命令解析与本地状态维护所有以/开头的输入当命令处理其余当聊天内容。第一版只做四个命令就够演示/list拉在线列表、/nick 新名字改名、/quit退出、/help看帮助。解析函数要能容忍多余空格和空参数用户在演示时手抖多打一个空格导致程序 panic是很难解释的事故。func Parse(input string) (cmd string, arg string, isCmd bool) { input strings.TrimSpace(input) if !strings.HasPrefix(input, /) { return , , false } fields : strings.Fields(input) // Fields 会自动合并连续空格 if len(fields) 0 { return , , false } cmd strings.ToLower(strings.TrimPrefix(fields[0], /)) if len(fields) 1 { arg strings.Join(fields[1:], ) } return cmd, arg, true }本地状态只有三样自己的昵称、是否已连接、最后收包时间。别在客户端缓存在线列表/list每次都从服务端拉缓存带来的“列表里有个已经下线的人”这种问题不值得。改名要发一条join帧让服务端走一遍重名校验服务端回sys确认后客户端才更新提示符中间状态用旧昵称避免两端口径不一致。4.3 断线处理与资源清理客户端退出必须走干净路径先发quit帧再Close连接最后关掉输入协程。少了任何一步都会出现“服务端在线列表里挂着幽灵用户”一直到心跳超时才消失演示时很难看。func (c *Client) Close() { c.once.Do(func() { protocol.WriteFrame(c.conn, protocol.MustJSON(protocol.Message{ Type: quit, TS: time.Now().UnixMilli(), })) c.conn.Close() // 先发 quit 再关连接顺序不能反 close(c.done) // 通知输入协程退出 }) }close(c.done)之后输入协程在select里立刻醒过来返回不会漏一个 goroutine 在那儿等Scan。CtrlC也要挂上信号处理走同一个Close否则 SIGINT 直接杀进程quit帧永远发不出去。这段代码不长但它是“看起来能用”和“能上台演示”的分界线。5. 排查与避坑粘包、慢客户端与广播发现失败的五种翻车现场这套程序功能不多可一旦进入真实的多机环境出问题的地方往往集中在几个固定位置。下面五条是我在不同机器组合上反复遇到的每条都按现象、原因、解决三步写清楚遇到问题时可以当检查表用。5.1 正在输入的内容被新消息顶断现象用户敲了半句话还没回车别人发来一条消息屏幕上自己那半行断开、错位甚至和对方的文字混在一行里。原因接收协程和输入协程同时向同一个终端写没有互斥终端的光标位置被两边抢。解决所有输出走同一个带锁的UI.Println写之前发\r\033[K清行、写完重绘提示符和残留缓冲区。另外把fmt.Print全部收进ui包禁止业务代码直接打印这样规则只需要维护一处。5.2 消息偶尔被截断或两条粘成一条现象短消息一切正常用户粘贴一段长文本时对方收到的内容少了一截或者一句话后面挂着半句别人的话。原因TCP 是字节流Write一次不代表对端Read一次能拿到完整数据用bufio.Scanner直接读net.Conn而没约定边界时分片位置完全随机。解决坚持长度前缀 io.ReadFull读包头和读载荷都必须读满服务端和客户端共用protocol包里同一份编解码禁止任何一处手写拼包。改完以后加一个测试连续发送 1 字节、1000 字节、60000 字节三条消息验证三条都能完整还原。5.3 一个人卡住全场消息延迟十几秒现象房间里某人切到后台或合上笔记本其他所有人的消息开始出现明显延迟等那个人彻底超时掉线后才恢复。原因服务端在广播循环里直接对每条conn.Write某个连接写不进去就阻塞整个循环而这个循环又可能持有读锁。解决每个客户端一条带缓冲的sendchannel广播只负责投递写操作在独立协程里带 5 秒写超时投递失败直接踢人。这个改动最有价值的地方不是性能而是把故障隔离在单个连接内。5.4 同网段却自动发现不到主机现象同一台交换机下的两台机器客户端广播出去没有任何响应手动输入 IP 却能连上。原因常见的三种只往255.255.255.255发多网卡机器从错误的网卡出去了系统防火墙拦了 UDP 探测包无线网络开了终端隔离客户端之间根本不能互通。解决遍历本机所有网卡按每块网卡的掩码算出定向广播地址各发一次日志里打印实际使用的网卡名和地址保留手动填 IP 的兜底入口别把自动发现做成唯一路径。排查时先确认是哪一层的问题ping通不代表 UDP 广播能通。5.5 Windows 控制台中文输出乱码现象同一份二进制在 Linux 上正常Windows 上中文变成一排问号或者输入的中文变成乱码。原因控制台代码页与程序输出的 UTF-8 不一致代码页 936 下按 UTF-8 写出去就是花屏。解决启动脚本里先执行chcp 65001再运行程序或者在程序启动时检测并提示同时确认源码文件本身是 UTF-8 无 BOMBOM 会让 Go 编译器把第一行当成非法字符。这类问题不是逻辑错误但答辩现场一出现观感影响比任何 bug 都大。6. 验收与答辩三轮演示脚本和一份可量化的检查表功能跑通只是一半能不能在有限时间里把方案讲清楚、把异常演出来是另一回事。我一般把验收拆成三轮第一轮走正常流程第二轮专门制造故障第三轮看指标。三轮加起来十几分钟覆盖了老师最可能问的所有点。第一轮三台机器或一台机器开三个终端。服务端启动并打印监听地址客户端 A、B 依次用昵称加入各自能看到“某某加入了房间”的系统提示A 发一条中文、一条带标点的长句B 和 C 都能收到且顺序一致B 执行/list显示三个人B 改名后 A 的界面出现系统提示且后续消息用新昵称。这一轮要控制在一分半内动作提前练熟别现场找命令。第二轮制造故障。客户端 C 直接关窗口不走/quitA、B 应在心跳周期内看到离线提示把 A 的网线拔掉或者禁用网卡服务端日志应打出写超时并踢人B 不受影响往客户端粘贴一段超过 60KB 的文本应被maxFrame挡住并给出提示而不是崩溃。这一轮是拉开差距的地方多数同学只演示正常路径你把异常演出来说明你知道边界在哪。检查项通过标准验证方式帧完整性1B / 1KB / 60KB 三条连续消息全部还原单独跑协议层单测并发接入20 个客户端同时加入昵称无冲突脚本循环起 20 个客户端掉线感知强杀客户端后 25 秒内其他人看到提示观察系统消息时间戳慢客户端隔离挂起一个客户端其余人消息延迟小于 200ms另开终端计时资源回收客户端全部退出后服务端 goroutine 数回落到基线runtime.NumGoroutine()打点中文输出两端中文与标点完整无乱码发送包含中英混排的句子第三轮看指标不用做得太复杂两条就够消息从 A 敲回车到 B 屏幕出现的时间局域网内正常在 10ms 量级服务端峰值 goroutine 数应接近“客户端数 × 2 加常数”如果客户端都退出了这个数字还不降说明有协程泄漏通常是writeLoop没收到 channel 关闭信号。把这两个数字写在答辩 PPT 的一页上比十页架构图更有说服力。答辩时最常被追问的三个问题提前准备好答案为什么不用 UDP 直接传消息——能传但你得自己做可靠性和顺序聊天场景 TCP 更省事为什么不用现成的消息队列——几十人的房间引入外部依赖是负收益如果要扩到跨网段怎么办——那要把发现改成手动配置服务端地址或者加一层中继控制台程序本身不需要变。回答时把边界讲清楚比硬答“都能做”可信得多。从那以后我每次交这类网络课设都会在写第一行业务代码之前先把协议层的 round-trip 测试和那份六项检查表列出来跑完再动界面返工次数少了非常多。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
