简介这是一份用 Go 语言实现的基于控制台的局域网聊天程序源码面向正在学习 Go 网络编程、想动手实践 TCP 通信与并发模型的开发者也适合作为课程设计或练手项目的起点。压缩包共 6 个文件以 4 个 go 源文件为主另含 server 与 client 两个可执行程序整体约 3.72MB源码按服务端与客户端拆分结构清晰便于对照阅读。程序实现了基本的聊天功能涵盖连接建立、消息收发与用户管理等核心环节读者可在此基础上扩展私聊、群组、文件传输或界面美化等功能。目前已有 221 人学习下载适合希望从零理解局域网即时通信原理、快速搭建可运行 Demo 并继续二次开发的 Go 学习者参考。1. 从零拆一个 Go 写的局域网聊天程序它到底能解决什么前阵子帮一个做硬件调试的朋友排查问题他们实验室十几台设备分散在同一个交换机下想临时传个日志文件、同步一下测试指令结果微信传文件被压缩、网盘又要登录折腾半天。后来我翻出一个用 Go 写的基于控制台的局域网聊天程序编译出来就一个二进制文件扔到任意一台机器上跑起来同一网段内直接就能互相发消息、传文本不需要服务器、不需要注册、不需要联网。这类工具在「go 局域网聊天程序」这个搜索词下其实一直有人找但真正能跑通、能看懂、能改的完整实现并不多。它本质上是一个基于 TCP/UDP 的 C/S 或 P2P 通信 Demo核心价值在于把网络编程里最常被问到的几件事——连接建立、消息广播、并发读写、粘包处理——用最小的代码量串起来。适合谁一是刚学完 Go 语法、想找个能跑的网络项目练手的人二是需要在隔离内网里做临时通信、不想依赖外部服务的运维或测试人员三是想拿一个干净骨架去改造成自己工具链的开发者。下面我按「怎么跑起来 → 核心机制怎么实现 → 哪里容易翻车 → 怎么改成自己的东西」这条线把它拆开讲。2. 跑通第一个版本编译、启动与双机验证2.1 环境准备与编译命令这个项目对 Go 版本要求不高常见做法是用 Go 1.18 以上因为会用到go mod管理依赖而且部分实现里用了泛型或any类型。先确认本机环境go version # 输出类似 go version go1.21.0 darwin/amd64 即可拿到源码目录后第一步是初始化模块并拉齐依赖。如果源码里已经带了go.mod直接下载依赖即可cd lan-chat go mod tidy # 如果源码没有 go.mod手动初始化 # go mod init lan-chat编译成单文件可执行程序这是它最舒服的地方——不依赖运行时拷走就能用# Linux / macOS go build -o lanchat main.go # Windows 交叉编译 GOOSwindows GOARCHamd64 go build -o lanchat.exe main.go逻辑说明go build会把所有依赖静态链接进一个二进制-o指定输出名。参数上GOOS和GOARCH决定目标平台常见组合是linux/amd64、windows/amd64、darwin/arm64。编译完先别急着分发本机跑一次看有没有 panic。2.2 启动参数与双机联调步骤这类程序通常有两种角色服务端监听端口、维护客户端列表和客户端连接服务端、收发消息。启动方式一般是命令行传参或交互式输入。典型启动流程# 机器 A启动服务端监听 8888 ./lanchat -mode server -port 8888 # 机器 B作为客户端连接 A 的局域网 IP ./lanchat -mode client -addr 192.168.1.10:8888 -name alice # 机器 C再起一个客户端 ./lanchat -mode client -addr 192.168.1.10:8888 -name bob逻辑说明-mode区分角色-port是监听端口-addr是服务端地址-name是显示昵称。参数怎么改端口建议选 1024 以上避免权限问题昵称用于消息前缀区分身份。验证是否跑通看三点服务端是否打印「client connected」B 发消息后 C 是否收到C 断开后服务端是否清理了连接。如果 B 连不上先ping通、再telnet 192.168.1.10 8888看端口是否可达最后查防火墙。提示同一台机器上测试多客户端时-addr用127.0.0.1即可但真实局域网场景一定要换成实际网卡 IP用ip addr或ipconfig查。2.3 目录结构与关键文件职责拿到源码先别通读按职责拆开看效率更高。常见结构如下文件职责阅读优先级main.go入口解析参数、启动对应角色高server.go监听、维护客户端 map、广播高client.go连接、发送、接收循环高protocol.go消息编解码、粘包处理中utils.go日志、时间戳、输入读取低先看main.go确认参数入口再看server.go的Accept循环和client.go的Read循环这两个循环是整个程序的心脏。protocol.go决定消息边界怎么切是后面避坑章节的重点。3. 核心机制拆解并发模型、消息广播与粘包处理3.1 goroutine channel 的并发读写模型Go 写网络程序最舒服的就是并发模型。服务端每接受一个连接常见做法是起一个 goroutine 专门读这个连接再起一个或多个 goroutine 负责写。读到的消息通过 channel 汇总到一个广播中心避免多个 goroutine 直接操作同一个连接导致数据竞争。// 服务端接受连接并为每个客户端启动读写 goroutine func (s *Server) handleConn(conn net.Conn) { client : Client{conn: conn, send: make(chan string, 16)} s.mu.Lock() s.clients[conn] client s.mu.Unlock() // 读 goroutine把收到的消息投递到广播 channel go func() { defer s.removeClient(conn) reader : bufio.NewReader(conn) for { msg, err : reader.ReadString(\n) if err ! nil { return } s.broadcast - fmt.Sprintf([%s] %s, client.name, msg) } }() // 写 goroutine只负责从自己的 send channel 取数据写回连接 go func() { for msg : range client.send { conn.Write([]byte(msg)) } }() }逻辑说明s.clients用sync.Mutex保护因为多个 goroutine 会并发增删。每个客户端一个带缓冲的sendchannel缓冲大小 16 是经验值太小容易阻塞广播、太大浪费内存。广播中心单独一个 goroutine 从s.broadcast取消息遍历 clients 投递到各自的send。这样读、写、广播三条线解耦任何一条慢都不会直接卡死其他连接。参数上bufio.NewReader的默认缓冲 4096 字节消息特别长时要调大或改用ReadBytes。3.2 消息广播与客户端上下线通知广播的核心是「一个人说话所有人收到」。但真实场景里还要处理上线、下线、昵称冲突。常见做法是定义几种消息类型用前缀或 JSON 区分// 简单的消息类型约定 const ( MsgChat CHAT MsgJoin JOIN MsgLeave LEAVE ) // 广播上线通知 func (s *Server) notifyJoin(name string) { s.broadcast - fmt.Sprintf(%s|%s 加入了聊天\n, MsgJoin, name) } // 广播中心 func (s *Server) broadcastLoop() { for msg : range s.broadcast { s.mu.Lock() for _, c : range s.clients { select { case c.send - msg: default: // 该客户端发送缓冲已满跳过避免阻塞全局 } } s.mu.Unlock() } }逻辑说明select加default是关键当某个客户端网络卡顿、sendchannel 满了直接跳过它而不是阻塞整个广播循环这是保证服务端不被单个慢客户端拖垮的常用手段。消息格式用类型|内容是最简方案改成 JSON 更规范但解析开销略大。上线通知在handleConn注册完 client 后调用下线通知在removeClient里调用注意先删 map 再广播避免给自己发。3.3 TCP 粘包与消息边界处理这是新手最容易翻车的地方。TCP 是字节流没有消息边界你发两次「hello」和「world」对面可能一次收到「helloworld」也可能分三次收到。控制台聊天程序如果直接用conn.Read读消息就会串在一起。常见解法有三种固定长度、分隔符、长度前缀。控制台聊天用分隔符最省事约定每条消息以\n结尾// 发送端确保每条消息以换行结尾 func sendMsg(conn net.Conn, msg string) error { if !strings.HasSuffix(msg, \n) { msg \n } _, err : conn.Write([]byte(msg)) return err } // 接收端用 ReadString 按分隔符切分 reader : bufio.NewReader(conn) for { line, err : reader.ReadString(\n) if err ! nil { break } line strings.TrimRight(line, \r\n) // 处理单条完整消息 }逻辑说明bufio.Reader.ReadString会一直读到分隔符才返回天然解决了粘包。参数上分隔符选\n是因为控制台输入本身按行用户不会在消息里打换行。如果消息内容可能含换行就得改用长度前缀先写 4 字节 int 表示长度再写内容接收端先读 4 字节再读对应长度。TrimRight是为了兼容 Windows 的\r\n不加的话消息末尾会多一个\r显示时看着像乱码。4. 避坑与排查那些让程序「看着能跑其实不能用」的细节4.1 客户端连不上先分清是网络不通还是端口没监听现象客户端启动后一直卡在「connecting」或直接报connection refused。原因通常分三层物理网络不通、服务端没监听、防火墙拦截。解决顺序是先ping 服务端IP确认二层可达再在服务端netstat -an | grep 8888看端口是否处于 LISTEN最后查服务端防火墙Linux 用iptables -L或firewalldWindows 看入站规则。血泪经验是很多人只查了前两步忘了服务端绑定的可能是127.0.0.1而不是0.0.0.0导致只监听本地回环局域网其他机器根本连不上。监听地址要写成:8888或0.0.0.0:8888。4.2 消息发出去对面收不到channel 阻塞与写超时现象A 发消息服务端日志显示收到了但 B 没显示。原因多半是 B 的写 goroutine 卡住了或者 B 的sendchannel 满了被default跳过。解决先给conn.Write加写超时conn.SetWriteDeadline(time.Now().Add(5 * time.Second))避免慢连接永久占用再检查sendchannel 缓冲是否过小高并发下调到 64 或 128。另外确认广播循环里没有在持锁状态下做阻塞操作锁的粒度要小。4.3 中文乱码编码与截断问题现象英文正常中文显示成问号或半个字。原因一是发送端和接收端编码不一致Windows 控制台默认 GBKLinux 默认 UTF-8二是按字节截断消息时把多字节字符切开了。解决统一用 UTF-8Windows 下在程序启动时调用chcp 65001切代码页如果必须按长度截断用[]rune转换后按字符数切不要直接切[]byte。这个坑在跨平台分发时几乎必踩。4.4 客户端异常退出导致服务端残留连接现象B 直接关窗口或拔网线服务端clientsmap 里还留着 B广播时一直往一个死连接写。原因是没有正确处理读 goroutine 的err返回。解决读循环里err ! nil时必须调用removeClient并且removeClient里要close(client.send)和conn.Close()。更稳妥的做法是加心跳服务端每隔 30 秒往每个连接写一个 ping连续两次写失败就清理。参数上心跳间隔别太短否则浪费带宽30 到 60 秒是常见区间。4.5 并发写同一个连接导致数据交错现象偶尔出现两条消息粘在一起或内容错乱。原因是多个 goroutine 同时往一个conn写。解决坚持「一个连接只有一个写 goroutine」的原则所有要发的数据都走sendchannel。如果确实有多个来源用sync.Mutex包住写操作。这个坑隐蔽性强本地测试量小看不出来一上多人就暴露。5. 进阶改造把它变成你自己的内网工具跑通原版只是开始这类骨架真正的价值在于改。我一般会先做三件事加心跳保活、把消息格式换成 JSON、加一个简单的文件传输通道。心跳前面提过重点说后两个。消息格式换 JSON扩展性立刻不一样。原来类型|内容只能传文本换成结构体后可以带时间戳、发送者 ID、消息 IDtype Message struct { Type string json:type // chat / join / leave / file From string json:from Content string json:content Time int64 json:time } // 发送时序列化 data, _ : json.Marshal(msg) sendMsg(conn, string(data)\n) // 接收时反序列化 var m Message if err : json.Unmarshal([]byte(line), m); err ! nil { // 非法消息丢弃并记录 continue }逻辑说明json.Marshal把结构体转成字节末尾仍加\n保持分隔符方案不变。Time用 Unix 时间戳跨时区显示时再本地化。反序列化失败要continue而不是break否则一条脏数据就能踢掉整个连接。文件传输可以复用同一套协议加一个file类型Content放 base64 编码的文件内容或者更高效的做法是协商一个临时端口单独传。控制台场景下 base64 最省事但要注意大文件会撑爆内存常见做法是限制单文件 1MB 以内超过就提示改用其他方式。验证改造是否成功我习惯用一个笨办法开三个客户端一个持续发消息、一个持续收、一个反复上下线跑十分钟看服务端内存和连接数是否稳定。从那以后我每次改完网络程序都强制走一遍「三客户端压测 断线重连 中文消息」这套流程基本能拦住八成低级问题。希望帮到你。本文还有配套的精品资源点击获取