简介易语言局域网聊天源码面向易语言初学者、在校学生及需要快速搭建局域网简单通信功能的开发者。源码以窗口程序集为骨架包含取时间、持续在线等基础逻辑并在启动窗口创建完毕时完成初始化通过修改、保存、发送等按钮事件实现交互代码中明确划分了启动窗口创建、按钮修改、按钮保存、按钮发送等子程序结构紧凑、事件分工明确适合用于学习易语言界面设计与事件驱动编程。整个压缩包仅7KB体量轻巧便于直接下载后阅读源码结构或作为二次开发起点参与学习人数已有69人。从中可以掌握易语言中按钮事件、时钟取时、在线状态维护等常见写法还可进一步将消息收发思路迁移到网络通信场景可作为课程设计或毕业设计的基础参考模块。1. 用易语言做局域网聊天先别急着写界面想清楚这三点“用易语言做局域网聊天”这个标题看起来平平无奇打开界面拖两个组件就能发消息但真正做起来卡住你的往往不是界面而是三个问题消息能不能完整送达、人多了会不会乱套、断线重连能不能接得上。这篇文章只讲一件事用易语言把局域网聊天做成一个不依赖外网、随时可改可扩展的轻量工具。它适合想在单位或宿舍内部搭一个私密聊天通道的开发者也适合拿网络编程入门练手的易语言新手。读完你能得到一套可复现的服务器-客户端最小实现以及协议设计、在线列表维护、粘包处理的关键参数和踩坑记录。2. 选对组件和协议易语言建局域网聊天前必须先定的事2.1 服务器/客户组件 vs 数据报组件TCP 和 UDP 怎么选易语言里能直接做局域网通讯的组件主要有两套一套是“服务器”加“客户”组件底层走 TCP一套是“数据报”组件底层走 UDP。聊天工具我建议直接用 TCP原因很直接TCP 是有连接状态的协议客户端一断线服务器立刻能感知UDP 只管发对方收没收不知道在线状态全靠自己维护做聊天等于把协议的活全干了。对比项TCP服务器/客户组件UDP数据报组件连接状态有断线可感知无需自己维护消息可靠性保证顺序和到达可能丢包、乱序易语言组件服务器、客户数据报适合场景聊天、文件传输、状态同步广播发现、心跳探测典型翻车点粘包、半包、句柄复用在线列表失效、消息悄悄丢局域网内 UDP 丢包率确实低但低不等于零。做聊天工具时一旦出现“消息发了但对方没收到”的情况UDP 方案很难排查因为你不知道是发丢了还是对方程序没处理。TCP 方案至少能保证消息要么到达要么连接断开你只需要处理断开后的重连逻辑。数据报组件并不是没用我一般只拿它做两件事一是启动时的服务发现——客户端广播“谁在运行聊天服务”服务器回应自己的 IP二是心跳探测的补充通道。真正的聊天消息、上线通知、下线通知全走 TCP。这样分工既避免了 UDP 的不可靠又解决了“客户端不知道服务器 IP 填什么”的体验问题。2.2 自定义通信协议为什么你的聊天工具总出乱码和串话很多初学者做局域网聊天时直接“客户1.发送数据 (到字节集 (编辑框内容))”服务器收到后“到文本 (数据)”就显示了。单机自测没问题两台电脑一连要么两条消息黏在一起分不开要么中文显示成乱码。核心原因一句话TCP 是字节流没有消息边界。你发的“你好”和“在吗”可能一次性到达服务器也可能“你好”被拆成两次到达服务器根本不知道一条消息从哪里开始、到哪里结束。所以第一步不是写界面而是定协议。我一般用的消息格式是这样一张表字段顺序固定双方严格按这个顺序组装和解析字段长度说明消息总长4 字节从类型字段到消息体末尾的总字节数用于切分消息消息类型1 字节1聊天2上线3下线4心跳5文件头发送者编号2 字节服务端分配的客户端短编号0 表示系统消息昵称长度1 字节昵称的 GBK 字节长度不是字符长度昵称变长GBK 编码的昵称文本消息体变长聊天内容或文件元信息为什么要用长度前缀而不是换行符分隔因为聊天的内容里很可能自带换行用换行做边界必炸。长度前缀是最省事的方案发消息前先算好总字节数填进前 4 字节收消息时先读前 4 字节知道整条消息多大再按这个长度切分。注意“昵称长度”这里用“字节长度”而不是“字符长度”——中文在易语言默认编码下一个字符占两个字节用取文本长度计算会导致服务器按字节切分时错位这是最常见的乱码根源。协议表定下来之后还要约定“最小消息长度”。我的协议里心跳消息最短结构是 4 字节总长 1 字节类型 2 字节编号共 7 字节。所以解析时如果缓冲区长度小于 7直接丢弃等下一批数据。这个边界条件写死在解析函数开头能省掉大量越界崩溃的排查时间。2.3 端口、连接数、缓冲区三个初始参数一次定好端口选择上不要用 1024 以下的知名端口容易和其他软件冲突也不要随手用 8080、3306 这类被开发工具占用的常见端口。我一般选 6000 到 9000 之间的一个冷门数字比如 7788冲突概率小又好记。启动前先检查端口是否被占用这个后面避坑章会专门说。最大连接数服务器组件启动时有一个参数可以设置。局域网聊天这种轻量场景50 个并发连接足够设太大会让易语言维护连接数组时白白消耗内存。如果你要带到教室或公司给几十号人用100 也够真正吃性能的是消息广播逻辑而不是连接本身。缓冲区是很多人忽略的点。我一般给每个客户端连接维护一个独立的接收缓冲字节集初始分配 4KB数据到达后先追加到缓冲再循环解析。为什么要独立缓冲因为多客户端同时发数据时如果共用一个全局缓冲两个客户的数据会混在一起消息就串了。每个连接一个缓冲按客户标识取出对应的缓冲来做累加这个设计从第一版就要做对不然后期改代码等于重写。3. 服务端实现连接管理、消息转发和在线列表的最小代码3.1 服务器组件事件客户进入、收到数据、客户离开服务端的核心是三个事件客户进入、收到数据、客户离开。先定义一个自定义数据类型来管理每个客户的状态这是整个服务端的地基.数据类型 客户连接信息 .成员 标识, 整数型 Windows socket 句柄每次连接唯一 .成员 编号, 整数型 服务端分配的短编号用于客户端显示 .成员 昵称, 文本型 上线消息带过来的昵称 .成员 接收缓冲, 字节集 解决粘包问题的关键缓冲区 .成员 最后心跳, 整数型 心跳检测用存最近一次心跳的取启动时间程序集变量里声明一个“客户连接信息”类型的数组用来存所有在线客户。客户进入事件只做一件事给这个连接分配一个递增的短编号并初始化其接收缓冲。.程序集变量 连接列表, 客户连接信息, , 0 .程序集变量 下一个编号, 整数型 .子程序 _服务器1_客户进入 .参数 客户标识, 整数型 .局部变量 新客户, 客户连接信息 新客户.标识 客户标识 下一个编号 下一个编号 1 新客户.编号 下一个编号 加入成员 (连接列表, 新客户)客户标识是 Windows socket 句柄不是 IP 也不是昵称。每次连接唯一断线重连会变。所以在线列表的主键必须用客户标识不能用昵称因为昵称可能重复。编号是另一套逻辑它只用来在聊天消息里标识“这条消息是谁发的”客户端拿到编号就能判断是不是自己发的。收到数据事件里不能直接解析消息因为一次事件收到的数据可能只是半条消息。正确做法是先把数据追加到对应客户的接收缓冲里再统一解析.子程序 _服务器1_收到数据 .参数 客户标识, 整数型 .参数 数据, 字节集 .局部变量 索引, 整数型 索引 取客户索引 (客户标识) 如果真 (索引 -1) 返回 连接列表[索引].接收缓冲 连接列表[索引].接收缓冲 数据 解析缓冲 (索引)客户离开事件相对简单找到数组里对应项先广播一条下线消息告诉其他人再从数组里移除。注意移除后数组下标会变所以取索引的操作每次都要重新做不能缓存起来跨事件用。3.2 在线列表怎么维护句柄和昵称的映射表在线列表的维护核心是“客户标识”和“昵称”的映射。客户进入时只有句柄没有昵称昵称要从客户端发的第一条上线消息里解析出来。所以收到数据后要先看消息类型如果是类型 2上线就把昵称填进连接列表对应项然后把当前在线列表发给新人再向其他人广播“有人上线”。.子程序 处理上线消息 .参数 索引, 整数型 .参数 昵称, 文本型 .局部变量 上线通知, 字节集 连接列表[索引].昵称 昵称 构造一条系统消息类型2、编号0、昵称固定为“系统” 上线通知 构造消息 (2, 0, “系统”, “新用户上线” 昵称) 广播消息 (连接列表[索引].标识, 上线通知, 假)这里有一个容易被忽略的需求新加入的人需要看到当前有哪些人在线。处理方式是服务端在收到上线消息后遍历连接列表把每个在线客户的昵称打包成一条文本消息发给新人。这个列表的分隔符要用“|”这类聊天内容里不太会出现的符号或者干脆用固定长度字段避免解析时又把内容切错。移除客户时我用“先标记后清理”的策略而不是边遍历边删。具体做法客户离开时先把它对应的数组项的“标识”置为 -1表示已失效然后广播下线通知。等到需要遍历在线列表时遇到标识为 -1 的项就跳过。为什么不用“删除成员”因为易语言的数组删除成员会移动后面所有元素客户上下线频繁时数组反复搬运很容易出现下标错乱。标记法牺牲一点点内存换来了稳定性。3.3 消息转发广播给谁、怎么排除发送者聊天消息的转发逻辑不复杂收到一条类型为 1 的消息把发送者的编号和昵称填进消息头然后转发给除发送者以外的所有在线客户。构造消息时要注意转发出去的消息里发送者编号必须改成实际发消息的人客户端才能正确显示“谁说了什么”。.子程序 广播消息 .参数 发送者标识, 整数型 .参数 消息内容, 字节集 .参数 是否含发送者, 逻辑型 .局部变量 i, 整数型 计次循环首 (取数组成员数 (连接列表), i) 如果真 (连接列表[i].标识 ≠ -1) 如果真 (是否含发送者 假 且 连接列表[i].标识 发送者标识) 到循环尾 () 如果真结束 服务器1.发送数据 (连接列表[i].标识, 消息内容) 如果真结束 计次循环尾 ()参数“是否含发送者”用来区分两种场景聊天消息一般不含发送者因为自己发的消息自己界面里已经显示过了但上线、下线通知要含发送者否则发起者看不到“我上线了”的系统反馈。第一次写的时候我没加这个参数结果上线下线通知要么所有客户端都收不到要么连自己也收到一份界面消息重复。服务器1.发送数据这个命令有个坑它没有返回值发送失败不报错。所以消息转发必须依赖客户离开事件来清理连接不能靠发送结果反推。某个客户端如果突然断网服务器可能在几十秒后才收到 TCP 超时通知这期间消息虽然“发出去”了但实际没人收到。心跳检测正是为了解决这个盲区后面第六章会说。4. 客户端实现连接、发送、显示的三件套4.1 连接服务器启动时连接失败时优雅提示客户端的连接逻辑比看上去复杂一点客户组件的“连接”方法是异步的调用后立刻返回不会告诉你成功还是失败。真正的结果要靠“连接成功”和“连接断开”事件来通知。所以连接代码一般是这个套路.子程序 连接服务器 .参数 服务器地址, 文本型 .参数 服务器端口, 整数型 已尝试连接 真 连接成功标志 假 客户1.连接 (服务器地址, 服务器端口) 时钟_连接超时.时钟周期 3000启动一个 3 秒的超时定时器如果 3 秒内没有收到连接成功事件就弹窗提示“连接超时请检查服务器地址和端口”然后把定时器周期设为 0防止重复弹窗。这个“假进度条”式的检查在易语言里很实用因为很难从“连接”方法的返回结果判断失败——它实际上不提供任何返回信息。连接成功后客户端要立刻发一条上线消息把自己的昵称告诉服务器。这条消息用的类型是 2昵称字段填当前用户昵称消息体可以为空。服务器收到后才会把这个客户端加进在线列表并回复一个包含自己编号的消息客户端拿到编号存为“我的编号”之后所有聊天消息里的发送者编号等于它就显示成“我”。4.2 发送消息按协议组装字节集组装消息是最容易出错的地方因为字段顺序、长度计算错一个字节服务器解析就全乱。我一般这样写.子程序 发送聊天消息 .参数 内容, 文本型 .局部变量 昵称编码, 字节集 .局部变量 内容编码, 字节集 .局部变量 消息体, 字节集 .局部变量 消息长度, 整数型 昵称编码 到字节集 (我的昵称) 内容编码 到字节集 (内容) 消息体 类型1字节 编号2字节 昵称长度2字节 昵称 内容 消息体 字节集 { 1 } 消息体 消息体 到字节集 (到短整数 (我的编号)) 消息体 消息体 到字节集 (到短整数 (取字节集长度 (昵称编码))) 消息体 消息体 昵称编码 消息体 消息体 内容编码 总长度 类型1 编号2 昵称长度2 昵称字节数 内容字节数 消息长度 1 2 2 取字节集长度 (昵称编码) 取字节集长度 (内容编码) 消息体 到字节集 (消息长度) 消息体 客户1.发送数据 (消息体)注意两个细节。第一昵称长度用“取字节集长度 (昵称编码)”而不是“取文本长度 (我的昵称)”。前面提过中文在一个字符占两个字节取文本长度会把“小张”算成 2但实际字节数是 4服务器按长度切昵称时会把内容的前两个字节吞掉。第二类型、编号、长度这些字段的字节数必须和协议表完全一致类型 1 字节、编号 2 字节、昵称长度 2 字节一个都不能改。易语言里“到短整数”转出来是 2 字节“到整数”是 4 字节用错了协议就错位了。组装完消息后调试期可以在发送前加一行“调试输出 (取字节集长度 (消息体))”和服务端收到的字节数对比能快速确认长度字段有没有算错。我当年第一次跑通就是靠这个笨办法定位问题——服务端收到的数据比客户端发送的少了 4 字节一查是昵称长度字段用了“到整数”占了 4 字节位置全错了。4.3 消息展示区分自己发的和别人发的客户端收消息比发消息简单但展示逻辑要花点心思。客户组件有一个“数据到达”事件收到字节集后先扔进客户端的接收缓冲再按同样的解析函数处理。解析出的消息里用“发送者编号”来判断显示格式.子程序 显示聊天消息 .参数 发送者编号, 整数型 .参数 发送昵称, 文本型 .参数 内容, 文本型 .局部变量 显示文本, 文本型 如果 (发送者编号 我的编号) 显示文本 “我” 内容 #换行符 否则 显示文本 发送昵称 “” 内容 #换行符 编辑框_消息记录.加入文本 (显示文本)这里一定不要用昵称来判断是不是自己因为昵称可能重复。同一个昵称两个人用服务端分配不同的短编号客户端靠编号才能分清“这句话是谁发的”。另外编辑框的自动滚动问题消息多了之后编辑框不会自动滚到底部新消息会藏在下面看不到。我一般是每次加入文本后设置“编辑框_消息记录.起始选择位置 取文本长度 (编辑框_消息记录.内容)”把光标强制移到最后实现类似微信的自动滚动效果。聊天记录的显示顺序也值得注意。客户端本地上发消息后立刻显示“我xxx”但服务器转发回来的消息里也包含自己那条如果不去重自己说的话会显示两遍。处理方法有两种一是本地发消息时光显示“我xxx”收到服务器转发且发送者编号是自己的消息时直接忽略二是本地完全不显示等服务器转发回来再显示。我推荐第一种因为本地显示没有网络延迟界面反馈快服务器转发回来的自己那条消息接收时判断“发送者编号 我的编号”就跳过。5. 避坑指南易语言局域网聊天翻车现场记录5.1 粘包和半包消息黏在一起、内容被截断现象两条消息合在一行显示或者一条很长的话只显示一半。 原因TCP 是字节流没有消息边界。服务器一次收到数据可能包含多条完整消息也可能只收到一条消息的前半截。如果收到数据后直接按“一条消息”处理要么把两条消息当成一条解析内容错乱要么缓冲区长度不够强行取消息导致数据丢失。 解决每个连接维护独立接收缓冲收到数据先追加然后循环解析。解析流程是检查缓冲长度是否大于等于 4不够则等待读取前 4 字节得到消息总长检查缓冲长度是否大于等于 4 消息总长不够则是半包等待从第 5 字节开始取出消息总长字节作为一条完整消息然后更新缓冲把已取出的部分从缓冲头移除接着循环解析下一条。这段逻辑可以写成一个独立的“解析缓冲”函数服务器和客户端共用同一套解析规则。5.2 端口被占用启动服务失败却没有任何提示现象服务器1.启动 (7788, 50) 调用后程序不报错但客户端怎么也连不上。或者调试时第二次按 F5 运行服务器组件启动失败主窗口照样弹出来。 原因Windows 端口被其他进程占用时易语言的服务器组件启动失败但不抛异常也不提供返回值供判断。常见场景是上一次调试的进程没有完全退出端口处于 TIME_WAIT 状态也可能是系统里其他软件占了这个端口。 解决启动服务器前先做一次端口检测。常见做法是用“网络。端口检测”或者干脆启动前先尝试用客户组件连接一下本机这个端口如果能连上就说明端口被占直接提示退出。另一种思路是换一个不常用端口减少冲突概率但这不是治本方案。治本方案是启动后立刻用“是否处于监听状态”之类的方式交叉验证拿不准就手动开一个 cmd 窗口执行“netstat -ano | findstr 端口号”看一眼。5.3 客户标识句柄复用断线重连后发错人现象某个人掉线后重新连上发消息时昵称显示成另一个人或者下线通知把不相关的人踢出了在线列表。 原因客户标识是 Windows socket 句柄系统在连接断开后可能把同一个句柄值分配给新连接。如果代码里只用客户标识做数组主键旧连接的数据没清理干净新连接进来时可能匹配到旧的数组项。 解决客户离开事件里必须把对应数组项的标识置为 -1并把昵称、缓冲全部清空而不是只做“移除成员”。同时新连接进入时不要复用旧编号编号始终递增。这样即使句柄值被系统复用数组里存的也是新连接的完整信息不会串号。另外服务端遍历在线列表时遇到标识为 -1 的项要么跳过要么在遍历结束后统一清理不要边遍历边删成员防止数组下标错乱。5.4 Windows 防火墙拦截本机正常别人连不上现象服务器程序在本机运行本机自己也开客户端连自己完全正常但局域网里其他电脑连不上一直提示连接超时。 原因Windows 防火墙默认拦截入站连接。本机连自己的回环地址不受防火墙入站规则限制所以自测永远通过一到真机联调就翻车。 解决第一次启动程序时Windows 防火墙会弹窗询问是否允许很多人直接点了取消。更稳定的做法是把监听端口固定在防火墙的高级设置里手动添加入站规则放行该 TCP 端口。实测这样配置后局域网内客户端秒连。还有一种开发期偷懒方案做调试时临时把防火墙的网络配置文件改成“专用网络”并关闭入站拦截联调完再打开但这只适合开发环境不建议给最终使用的人这样做。5.5 中文乱码昵称和内容错位显示问号现象客户端发的消息服务器端收到的文本前半段正常后半段是乱码或问号昵称越短越正常昵称一长就必现。 原因组装消息时用“取文本长度 (昵称)”计算昵称长度但中文在易语言默认编码下是两字节一个字符。服务器拿到长度后按字节数切分昵称实际切出来的比真实昵称少一半字节导致后续内容字段的起始位置错位。 解决所有长度字段一律用“取字节集长度 (到字节集 (文本))”计算也就是先转字节集再取长度。协议里凡是“长度”字段含义都是字节长度而不是字符长度。客户端和服务器两端都要遵守这个约定。另一个相关的坑是易语言里文本默认用 GBK 编码如果你的聊天工具要和别的语言写的客户端对接编码问题会更明显那就得在协议里显式约定统一编码或者干脆传输时全部用 UTF-8 再转码。6. 把聊天工具往前推一步心跳检测和文件传输的思路基础聊天跑通之后下一个要解决的是“死连接检测”。TCP 连接在异常断开时服务器可能几分钟后才感知期间发消息发不出去、在线列表还显示着掉线的人。常见做法是心跳检测客户端每 5 秒发一条类型为 4 的空消息服务器收到后更新这个连接的“最后心跳”时间。服务器用一个定时器每 10 秒扫一遍所有连接如果“当前时间 - 最后心跳”超过 15 秒就按客户离开处理。这样掉线的人最多 15 秒内就会被清出在线列表。.子程序 _时钟_心跳周期 .局部变量 i, 整数型 .局部变量 当前时间, 整数型 当前时间 取启动时间 () 计次循环首 (取数组成员数 (连接列表), i) 如果真 (连接列表[i].标识 ≠ -1 且 当前时间 - 连接列表[i].最后心跳 15000) 强制下线 (连接列表[i].标识) 如果真结束 计次循环尾 ()文件传输是聊天工具另一个高频需求。我的做法是在协议里新增类型 5消息体前 8 字节放文件总长度然后按 4KB 一块分块发送每一块单独走客户端发送方法。接收端先收文件头再累积收到的大小达到总长度后写文件。不要尝试在大编辑框里显示文件内容那是性能灾难。文件传完后发一条类型 1 的聊天消息“文件已接收”。还有一个提升体验的小技巧UDP 广播做自动发现。客户端启动时向 255.255.255.255 广播一条“聊天服务发现”消息服务器收到后回复自己的 IP 地址客户端自动填入服务器地址省去手动输入 IP 的环节。注意要限定只在局域网内可用广播地址不要跨网段发。做这个工具我最大的教训是一开始先画界面拖好组件写事件结果协议没定联调时被粘包和编码问题折腾了整整一个晚上。后来我先把消息格式写成一张表格再动手敲代码一个晚上就全部跑通。所以如果你也在做这个方向建议第一步不是开 IDE而是先把协议定下来。希望帮到你。本文还有配套的精品资源点击获取