简介《征途》服务端与客户端源码压缩包面向游戏开发学习者、服务端架构研究者以及C/C程序员目标是还原一款经典MMORPG从账号登录到战斗同步的完整底层实现。内含服务端源码由C/C编写可用来分析玩家交互、游戏逻辑、任务调度、网络通信协议与状态同步机制客户端源码涉及DirectX/OpenGL图形渲染能够研究渲染管线、动画播放、物理碰撞及AI行为数据库部分则给出玩家数据、道具信息和游戏进度的存储结构配合《素材说明.txt》可快速理解源码目录、编译环境与依赖关系。压缩包共2000个文件以h和cpp源文件为主另有xml配置、lua脚本、asm汇编、hpp头文件以及vcproj/makefile/sln等构建工程文件便于按模块检索与本地编译整个压缩包约133.39MB。目前已有2920人浏览学习。对想从代码层面掌握大型游戏架构的开发者而言这份源码不仅能用于剖析网络同步与逻辑拆分方法还能帮助借鉴大规模在线项目的数据库设计思路是一份难得的完整工程参考。1. 一套《征途》三端源码包能跑起来才算数当一份《征途》服务端源码、客户端源码加数据库的资源包从爱给网这类素材站落到本地九成的人会直接双击客户端 exe然后盯着黑屏发呆。我的建议正好相反先别碰任何可执行文件把 zip 里的 .sln、.sql 和 .conf 当成主角。这套东西不是拿来即玩的成品而是一台需要自己点火的引擎跑通它需要你依次完成服务端编译、数据库导入、客户端对接三步任何一步断了游戏就停在登录界面之前。适合谁想研究早期 MMO 网络架构的开发者、拿复古私服做课程设计的学生以及单纯想把「跑不起来」变成「能注册能进图」的折腾型玩家。2. 拆包与文件结构服务端、客户端和数据库的定位先从目录看起拿到 zip 之后我一般不会急着点开任何一个 exe而是先看压缩包内部的顶层目录。这类多手转存的资源包有个共同特征目录名被前人改过无数次从「最终版」「真端」到「修复版3.0」什么都有命名已经完全不具备参考价值。你要做的不是记住目录名而是按文件类型把它们重新归类成四堆:服务端源码、客户端源码、数据库文件、工具与文档。归类对了后边的编译和联调才有坐标系。2.1 服务端源码的目录骨架从进程划分反推文件夹职责《征途》这类早期 MMO 的服务端源码目录结构一般按进程来划分。历史版本里常见到的是登录服负责账号验证和服务器列表下发逻辑服承载地图、怪物、NPC 和任务世界服处理跨区交互、国战、排行榜这类全局玩法数据库代理则统一封装所有 SQL 访问。你在根目录里看到 Server、World、Game、DB 这类命名的文件夹多半就是这几个进程的工程目录只是叫法各异。判断标准很简单哪个文件夹里有独立的 .vcproj 或 .sln哪个就是一个可编译的服务端工程。为什么逻辑服不直接连数据库非要中间架一个数据库代理这是我建议你拆包后第一个搞清楚的架构点。逻辑服直接连库意味着每条 SQL 都要经过网络握手和鉴权连接无法复用而且一旦逻辑服代码被攻破数据库账号直接暴露。数据库代理把连接池和 SQL 校验收敛到一个进程里逻辑服只发协议不碰 SQL 字符串。你在后边编译和配库时如果发现服务端工程列表里有个叫 DBProxy 或 DBServer 的工程别犹豫先确认它存在——很多精简版把数据库代理砍掉最后登录链路永远断在半路。2.2 客户端源码的目录骨架登录器、主程序和资源包的边界客户端源码的工程边界比服务端更清晰登录器工程和主游戏工程是两个独立解决方案资源包是第三个组成部分。登录器的职责只有三件事:检查资源版本、验证账号、拉起主程序。主程序才负责渲染、寻路、战斗和 UI。很多第一次跑私服的玩家会困惑「为什么登录器和游戏是分开的」原因在于那个年代的更新模式:官方通过登录器做增量补丁资源校验失败就下载最新包所以登录器里必须内置服务器列表和版本号而这个列表恰恰是你联调时最常改的地方。资源包则是另一个容易混淆的概念。如果你在客户端源码里看到大量 .pak、.tga、.map 后缀的文件那不是源码是资源。源码目录里的资源目录通常只是路径引用真正的资源体积动辄几个 GB往往作为独立 zip 分卷存在。拆包后你要确认三件事资源包是否完整、资源目录路径是否与源码里的相对路径一致、登录器的版本校验文件是否在资源包里。这三件事只要有一件对不上进游戏后轻则花屏重则直接崩溃。2.3 数据库脚本与工具.sql 与 .bak 的取舍以及一张关键表数据库文件在包里通常有两种形态.sql 建库脚本和 .bak 备份文件。.sql 适合全新搭建因为它忠实记录了表结构、索引和初始数据你可以在自己的 MySQL 实例里从头执行.bak 则是一个时间点快照适合想直接跳到「有人物、有装备」状态的人。我的建议是优先用 .sql 而不是 .bak原因很现实.bak 的还原依赖 MySQL 版本和系统库路径跨版本还原经常报错而 .sql 只要字符集选对了几乎不会失败。先别急着导入,拿到 .sql 后我习惯先做一次「只读侦查」看库里面到底有哪些表。用 grep 把 CREATE TABLE 语句全抓出来你就能快速了解这个库的规模。重点关注账号表、角色表和角色物品关系表。角色和物品是一对多角色和技能是多对多多对多关系会有一张中间表维护这里的数据冗余和索引设计直接决定了后边增删改查的流畅度。你如果能在这个阶段就把账号表的主键和唯一索引看清楚第 4 章的重复注册、主键冲突问题就不会让你抓瞎。# 在 Git Bash 或 WSL 下先解压再看表结构 unzip -q 《征途》服务端源码客户端源码数据库_爱给网_aigei_com.zip -d zt_src cd zt_src # 找到 .sql 后只提取建表语句不真正执行 grep -n CREATE TABLE ./DB/*.sql | head -30参数说明unzip 的 -q 是静默解压避免输出刷屏-d 指定解压目标目录。grep -n 会把匹配行和行号一起输出head -30 限制只显示前 30 条防止表太多刷屏。如果你在 Windows 下用 unzip 后遇到中文文件名乱码别慌那是编码显示问题用 7-Zip 右键解压通常就正常了不影响文件本体。2.4 用文件比对确认三端版本先解决版本一致性问题三端分离的源码包最恶心的坑就是版本不匹配。服务端逻辑是 2007 年的客户端资源是 2008 年的数据库脚本又是第三种来源三者在协议字段和资源版本上各说各话表现出的现象却是一样的登录无响应、选角色后断线、进图秒崩。所以拆包后第一件事不是编译而是确认三个端是否来自同一个母本。常见的做法是比对客户端和服务端共同依赖的配置文件。登录器里的服务器列表、服务端的网络配置、数据库里的版本号表这三处会有交叉字段。用 diff 比对文本文件能快速发现偏差二进制资源则用哈希校验。我一般会找两个文件做基准比对:客户端登录器里的资源版本号文件服务端配置里的版本控制字段。两者如果对不上后边联调就是地狱难度。# 比对文本配置diff 输出为空说明完全一致 diff ./Client/config/serverlist.ini ./Server/config/serverlist.ini # 比对二进制文件用 MD5 哈希确认是否为同一文件 certutil -hashfile ./Client/res/version.pak MD5 certutil -hashfile ./Server/version.pak MD5参数说明diff 命令在 Git Bash 下可以直接使用输出为空表示两个文件逐字节一致有输出时 开头是第一个文件的差异行 开头是第二个文件的差异行。certutil -hashfile 是 Windows 自带工具第一个参数是文件路径第二个参数指定哈希算法MD5 足够用来判断文件是否相同。如果两个哈希值不一样说明这个文件在转存过程中被改过或者本身就是不同母本的产物。3. 服务端源码编译与启动从解决方案文件到 GameServer 进程目录结构摸清楚之后下一步是把服务端源码变成能跑的进程。这个阶段的痛苦指数最高因为老工程的编译环境和现在的 Windows 差距很大很多源码包在转存时还缺了公共库文件。我的经验是先别追求一次编译通过先让解决方案能打开再按依赖顺序逐个工程生成最后才谈启动。3.1 用 VS 打开解决方案识别工程间的依赖关系在服务端源码根目录找到 .sln 或 .dsw 文件用 Visual Studio 打开。那个年代的 MMO 服务端源码大多是 VS2005 或 VS2008 的工程新版 VS 打开时会提示做一次工程升级确认即可。打开后你会看到解决方案下挂着多个工程公共库工程命名常带 Common、Core、Network、Utility 之类的词、逻辑服工程GameServer 或 ZoneServer、世界服工程、数据库代理工程以及一些 GM 工具和地图编辑器。先别急着点生成右键每个工程查看「项目依赖」把依赖关系画出来。依赖关系决定了编译顺序。公共库是所有服的基础逻辑服依赖公共库世界服依赖公共库数据库代理也可能依赖公共库。如果你跳过公共库直接编 GameServer编译器找不到头文件和 .lib报错会像瀑布一样刷屏。所以我把编译顺序固定成一条线公共库 → 数据库代理 → 登录服 → 逻辑服 → 世界服。按这个顺序每个工程失败时的错误信息都指向自己的问题而不是上一层的缺失。3.2 编译配置与参数Release、Win32 和字符集的选择编译前有三个配置必须检查解决方案配置选 Release 还是 Debug、平台选 Win32 还是 x64、字符集选 Unicode 还是多字节。老源码基本只能编 Release Win32。原因很直接那个年代的代码大量使用 char* 和 sprintf依赖多字节字符集改成 Unicode 会引来几百个类型转换报错x64 更不用说指针宽度变了很多隐式转换直接编不过。Debug 配置可以编但运行时依赖调试版运行时库部署时少带一个 DLL 就起不来Release 反而省心。命令行编译比在 IDE 里逐次点击更适合反复尝试我一般用 devenv 或 msbuild 做整条编译链。如果你装的是 VS2008devenv 路径里的 Visual Studio 9.0 就是它装新版 VS 的话 msbuild 更顺手。编译哪几个工程取决于你的解决方案名称我建议先编公共库和数据库代理两个工程跑通后再编逻辑服和世界服。一次编整个解决方案不是不行但第一个工程就报错时你分不清是依赖缺失还是代码不兼容。# 用 devenv 编译指定工程Release Win32 /c/Program Files (x86)/Microsoft Visual Studio 9.0/Common7/IDE/devenv.exe Server.sln /build Release|Win32 /project DBProxy # 新版 VS 可以用 msbuild/m 表示多核并行 msbuild Server.sln /p:ConfigurationRelease /p:PlatformWin32 /m参数说明/build 后面的 Release|Win32 是解决方案配置名和平台名的组合必须和你 .sln 里的名字完全一致否则会报「配置无效」/project 参数只生成指定工程不生成整个解决方案。msbuild 的 /p:Configuration 和 /p:Platform 作用相同/m 开启多核编译能明显加快速度但内存小的机器建议去掉避免编译中途内存耗尽。编译成功后去工程的输出目录找 .exe一般会在 Bin 或 Debug 目录下。3.3 服务端配置检查IP、端口、数据库连接串和机器码编译通过只是起点启动才是分水岭。启动前要检查服务端配置配置一般散落在 ini、conf 或 cfg 文件里我用一套固定检查清单过网络配置、数据库配置、机器码配置。网络配置包含本机 IP、监听端口、服务器列表本机单机测试全部填 127.0.0.1 没问题数据库配置包含 MySQL 地址、端口、账号、密码、库名这里的账号密码要和你第 4 章导入数据库时设置的一致机器码配置是流传版本偶尔带的东西绑定服务器 MAC 地址或主板信息不处理的话进程起来了但拒绝服务。数据库连接串是最容易出错的。很多版本在配置里默认写的是 root 空密码而你自己装的 MySQL 设了密码服务端启动后日志提示连接数据库失败却不说原因。我的建议是先用命令行工具手动连接一次确认账号密码和库名都正确再回过来看配置文件。另外注意连接串里的端口MySQL 默认 3306但如果你为了省事改了端口服务端配置里也要同步改。[Database] Server127.0.0.1 Port3306 Userroot Password123456 DBNamezt_game Charsetgbk [Network] LoginIP127.0.0.1 LoginPort6000 GameIP127.0.0.1 GamePort7000 WorldIP127.0.0.1 WorldPort8000参数说明Charsetgbk 不是可选项。老游戏客户端的文本编码就是 GBK数据库字符集和连接字符集必须跟着客户端走否则游戏里中文全是问号。数据库连接串里的账号权限建议直接给全权限私服环境没必要抠最小权限排查问题时权限不足的报错会让你误判成连接失败。3.4 第一次启动的验证动作日志、端口和进程配置改完后启动顺序有讲究。常见做法是先启动数据库代理再启动登录服最后启动逻辑服和世界服。数据库代理依赖 MySQL登录服依赖数据库代理下发账号数据逻辑服和世界服依赖登录服注册成功。顺序错了后启动的进程会在日志里反复打印重连失败看似起来了其实没进入服务状态。启动后先看日志再看端口。日志是黑匣子服务端正常运行会打印监听成功、连接数据库成功、服务器注册成功这类关键字报错时则会打印连接失败、拒绝访问、端口占用。端口验证用 netstat进程验证用 tasklist。如果你启动的服务端监听端口和配置里的端口不一致最常见原因是包里有多份配置文件另一个进程读的是别的 ini。这时候我一般直接在源码里全局搜索端口号把引用它的文件全部找出来逐个比对比凭感觉改配置可靠得多。# 查看 6000-8000 段的端口监听确认服务端进程是否真的在听 netstat -ano | grep -E 6000|7000|8000 # 查看服务端进程是否存活 tasklist | grep -E DBProxy|LoginServer|GameServer|WorldServer参数说明netstat -ano 中的 -a 显示所有连接和监听端口-n 用数字形式显示地址和端口-o 显示所属进程 PIDgrep -E 用正则匹配多个端口避免一条条查。tasklist 输出进程列表grep 过滤进程名。如果端口监听了但进程列表里没有对应进程名说明可执行文件被改过名以任务管理器里的 PID 为准去反查。第一次启动时多花五分钟确认端口和进程都对得上后边联调能省两小时。4. 数据库导入与账号链路从建库到角色存档落地的增删改查服务端编译完成只是拿到了骨架数据库导入才是让游戏「有数据可读」的关键。这个阶段你不再碰 C全部操作在 MySQL 命令行里完成。数据库是整个私服的数据底座账号验证、角色列表、物品存档、跨区同步全走它。我见过太多人把时间耗在服务端编译上最后却因为库没导对卡在登录界面一步都进不去。4.1 mysql 命令行导入建库、导表、刷初始数据的完整命令在导入 .sql 之前先确认两件事MySQL 服务是否已经启动、root 账号能否登录。然后用命令行建库并导入。字符集这一步万万不能省我建议建库时直接指定 DEFAULT CHARACTER SET gbk而不是用 MySQL 默认的 utf8mb4。原因在第 3 章提过客户端里的文本是 GBK 编码数据库按 UTF-8 存储中文读出来就是乱码而且这种乱码是「写入时就坏了」不是显示问题事后转换很难救回来。# 建库指定 GBK 字符集排序规则用 gbk_chinese_ci mysql -uroot -p -e CREATE DATABASE IF NOT EXISTS zt_game DEFAULT CHARACTER SET gbk COLLATE gbk_chinese_ci; # 导入把 .sql 文件送进 zt_game 库 mysql -uroot -p zt_game ./DB/zt_game.sql # 验证列出所有表名确认导入没有半途而废 mysql -uroot -p -e SHOW TABLES FROM zt_game;参数说明-u 指定用户名-p 表示需要密码输入-e 后面直接跟 SQL 语句适合一条条执行。CREATE DATABASE 的 IF NOT EXISTS 是幂等写法重复执行不会报错。导入时把 .sql 文件通过重定向符 喂给 mysql 进程库名 zt_game 必须放在用户名之前作为目标库。《征途》的 .sql 脚本一般很大导入过程可能持续几十秒如果中途报错中断不要重复执行整个脚本因为前面已经写入的表和后面要执行的语句可能冲突先定位报错行更实际。导入完成后用 SHOW TABLES 确认表数量。如果你的 .sql 是按模块拆分的多个文件比如账号库和角色库分开那就分别导入到同名库中服务端配置里的库名要和这里保持一致。很多人在这里翻车建了库、导了表但服务端配置里写的是另一个库名结果服务端连上了 MySQL 却查不到表。4.2 账号验证与角色加载连接池和 SQL 查询链路数据库就位后整个登录链路才能走通客户端把账号密码发给登录服登录服通过数据库代理查账号表返回账号 ID 和状态客户端拿到服务器列表后选择登录目标逻辑服再通过数据库代理加载角色列表。这条链路里有三个环节都可能断:数据库代理没起来、连接池里的连接耗尽、SQL 查询超时。连接池是服务端启动时初始化的一组数据库连接逻辑服每次查询从池里借用连接用完归还。连接池太小登录高峰期查询全部排队表现就是客户端转圈很久才出角色列表。排查连接池问题最直接的命令是 SHOW PROCESSLIST它能列出所有当前连接到 MySQL 的连接、所在库、执行中的 SQL。如果看到大量连接处于 Sleep 状态但池不够用说明连接没有被归还如果看到某个查询长期处于 Query 状态说明 SQL 效率有问题或者表被锁住了。这里我要强调一个常用命令习惯不要只查一次连续查两次间隔几秒看同一个 SQL 的耗时是否在增长。单次快照看不出问题趋势才能暴露慢查询。-- 查看当前所有数据库连接关注 State 列 SHOW FULL PROCESSLIST; -- 手动模拟登录服查账号按用户名查账号状态 SELECT id, username, status, last_login_ip FROM account WHERE username test001 LIMIT 1;参数说明SHOW FULL PROCESSLIST 的 FULL 关键字会显示完整 SQL 文本不加 FULL 时超长 SQL 会被截断。查询 account 表时status 字段一般表示账号状态0 为正常非 0 可能是封禁或禁言这个字段的取值因版本而异以你的 .sql 里的注释为准。LIMIT 1 是防御性写法防止表中意外存在重复用户名时返回多行导致程序解析出错。4.3 存档写入与数据同步事务、唯一约束和热更游戏服务端对数据库的写入集中在三个场景角色创建时插入角色下线时存档更新删除角色时清理从表。这三个操作分别对应增删改查里的增、改、删。角色创建和存档更新必须放在事务里执行因为一次操作涉及多张表——角色基础表、角色物品表、角色技能表任何一张表写入失败整个操作都要回滚否则会出现角色建好了但背包是空的这种数据残缺。唯一约束是第二个高频坑。account 表的 username 字段通常会加唯一索引你在测试时反复用同一个用户名注册第二次插入就会报 duplicate entry。这个报错信息很直白但很多人没意识到这是唯一索引在保护数据反而以为数据库坏了。处理方式有两种注册接口先查询再插入或者用 INSERT IGNORE 语法直接忽略冲突。-- 事务创建角色并初始化背包要么全成功要么全回滚 START TRANSACTION; INSERT INTO role (account_id, name, level, map_id, gold) VALUES (1001, 测试角色, 1, 1001, 1000); INSERT INTO role_item (role_id, item_id, count) VALUES (LAST_INSERT_ID(), 888, 10); COMMIT; -- 唯一冲突时用 INSERT IGNORE 忽略重复注册 INSERT IGNORE INTO account (username, password, status) VALUES (test001, e10adc3949ba59abbe56e057f20f883e, 0); -- 查询刚插入的角色 ID便于后续操作 SELECT LAST_INSERT_ID();参数说明START TRANSACTION 和 COMMIT 之间是一个事务中间的 INSERT 要么全部提交要么全部回滚。LAST_INSERT_ID() 是 MySQL 提供的会话级函数返回当前连接上一次自增插入的 ID用它填充 role_item 的外键避免在应用层再查一次。INSERT IGNORE 遇到唯一索引冲突时不会报错而是静默跳过返回值里影响行数为 0应用层可以根据这个行数判断注册是否成功。数据同步是另一个容易被忽视的点。私服环境没有官方那种跨服同步软件常见做法是把跨区数据国战、排行榜的写操作放到数据库代理进程里的一个异步队列避免多个逻辑服同时写一张表。如果你打算开多区先想清楚哪些表是全区共享的哪些是分区独立的共享表的写入一定要经过这个队列。这是并发问题的根源也是死锁的温床。4.4 数据库死锁与连接异常服务端闪断时的排查方向数据库死锁在这个老架构里并不罕见现象很典型服务端日志突然打印 Deadlock found然后某个逻辑服的线程卡住玩家操作无响应过一会整个进程被重启。原因通常是两个连接以不同顺序锁定了同一组记录。比如跨区战斗时A 服先更新角色表再更新排行榜B 服先更新排行榜再更新角色表两边的锁互相等MySQL 检测到死锁后回滚其中一个事务。排查死锁不要靠猜用 MySQL 自带的诊断命令看现场。SHOW ENGINE INNODB STATUS 会输出最近一次死锁的详细信息包括涉及的表、索引、持有锁的 SQL 和等待锁的 SQL。信息很长重点看 LATEST DETECTED DEADLOCK 段落。定位到涉及的表之后解决方向有三个让所有逻辑服对同一组表的更新顺序保持一致、把长事务拆成多个短事务、把跨服同步从同步写改成异步队列。第三条最省事也是我优先做的方案。-- 查看 InnoDB 引擎状态重点看死锁信息段落 SHOW ENGINE INNODB STATUS\G; -- 查看当前被锁阻塞的查询 SELECT * FROM information_schema.INNODB_TRX;参数说明SHOW ENGINE INNODB STATUS 输出很长\G 让结果按行垂直显示方便阅读。INNODB_TRX 表列出所有未提交事务可以看到哪个事务一直持有锁、已经运行了多久。如果事务时间特别长但状态是 Sleep说明应用层拿到连接后没有及时提交这种连接泄漏才是死锁和连接池耗尽的深层原因。排查时先看有没有长时间未结束的事务再看死锁信息顺序不要反。5. 客户端源码对接与联调登录器、补丁和资源路径的排查清单服务端跑起来了数据库也导进去了最后一步是把客户端源码编译好并和服务端对接。这个阶段遇到的问题最琐碎也最考验耐心。客户端源码不像服务端那样按进程分得清清楚楚登录器、主程序、资源包三者之间的引用关系容易让人一头雾水。我把客户端联调当成一个「排查闭环」来做编译 → 配置 → 联调 → 验证每一步出了问题都有对应的检查位置。5.1 客户端源码的编译入口登录器和主程序是两套工程打开客户端源码根目录你会看到至少两个解决方案登录器解决方案和主程序解决方案。登录器编译出来的 exe 负责版本检查和账号验证主程序编译出来的 exe 负责游戏渲染和逻辑。很多包还会多一个资源工具工程用来打包和解包 .pak 资源文件。第一次编译客户端时只编登录器和主程序就够了资源包不需要重新打包下边的修复建议先用包里的原始资源把流程跑通再考虑改资源。登录器的特殊之处在于它会在启动时校验资源版本如果版本号和服务器端配置的不一致登录器会尝试下载补丁。本地联调时没有补丁服务器下载必然失败所以你要么在登录器配置里把版本校验关掉要么把资源版本号改成和服务端一致。这个开关在不同版本里的位置不一样常见在登录器的配置头文件里是一个 VERSION 或 RES_VERSION 的常量。改完后重新编译登录器这一步不做后边所有联调都会被「版本不一致」这个提示挡在门外。5.2 IP 绑定与登录器配置客户端连不上服务端时看哪里客户端连不上服务端90% 是配置问题而不是代码问题。联调前先理清三个配置文件登录器读的服务器列表配置、主程序读的网络配置、服务端进程读的监听配置。三者必须互相匹配。服务器列表配置里的 IP 和端口指的是登录服的地址主程序里配置的 IP 和端口指的是逻辑服的地址服务端监听配置决定它到底听在哪个 IP 和端口上。本机单机测试全部用 127.0.0.1 是最省心的。如果你想在局域网里用另一台机器玩配置就不是 127.0.0.1 这么简单了。服务端监听配置要改成 0.0.0.0 或者这台机器的局域网 IP客户端配置要填这台机器的局域网 IP两边都不能错。注意服务端监听 127.0.0.1 时局域网内其他机器无论如何都连不上这是 bind 地址的问题不是防火墙的问题。改完配置后先确认服务端确实监听了新地址再让客户端去连顺序别反。; 登录器服务器列表LoginIP/LoginPort 指向登录服 [ServerList] Count1 ServerName本地测试服 LoginIP127.0.0.1 LoginPort6000 ; 主程序网络配置GameIP/GamePort 指向逻辑服 [Network] GameIP127.0.0.1 GamePort7000参数说明配置文件是 ini 风格分号开头是注释实际解析时会被忽略。Count 表示服务器列表数量如果你配置了多组服务器Count 要相应增加。LoginIP 和 LoginPort 是登录服的地址GameIP 和 GamePort 是逻辑服的地址。本机测试时端口必须和服务端配置里的一致服务端登录服监听 6000客户端却填 7000登录请求会直接发到逻辑服端口上逻辑服根本不处理登录协议表现就是转圈无响应。5.3 联调最常见的 5 个坑现象、原因与处理把所有配置填对之后剩下的就是实测。以下 5 个坑是我在不同版本的征途源码上反复遇到过的按现象、原因、处理三段式拆开你按顺序排查即可。第一登录器点登录一直转圈不回包。现象是进度条永远走不完界面不报任何错误。原因是登录服没收到请求或者收到请求但数据库代理没起来登录服无法查库。处理方式先看登录服日志有没有收到登录请求再看数据库代理进程是否存活最后用第 4 章的 SHOW PROCESSLIST 确认登录服确实在查库。第二能登录但角色列表为空创建角色后也看不到。现象是登录验证通过了但进入选角色界面后一片空白。原因是数据库连接串指向了错误的库或者角色表里根本没有对应账号的数据。处理方式用 4.2 的 SELECT 语句手动查 account_id 对应的角色记录如果查询结果为空说明角色写入没成功回去看 4.3 的事务有没有提交。第三进入游戏后 30 秒内掉线日志显示连接重置。现象是角色能进图画面加载出来了但很快被踢回登录界面。原因是逻辑服和世界服之间的同步配置不对逻辑服向世界服注册失败或者心跳超时被断开。处理方式检查逻辑服配置里的 WorldIP 和 WorldPort确认和世界服的监听配置一致再确认启动顺序是数据库代理 → 登录服 → 世界服 → 逻辑服。第四游戏内地面、UI 花屏或者闪退。现象是画面渲染异常严重时主程序直接崩溃退出。原因是客户端资源包版本和主程序代码不匹配或者资源包不完整。处理方式先确认资源包是从原始母本解出来的不要混用不同版本的 res 目录再用第 2.4 节的哈希比对确认资源校验文件和登录器里的版本号一致。这类问题排查到最后往往很像玄学其实就是资源版本错位。第五数据库中文乱码账号可以注册但名字是问号。现象是游戏里创建的角色名、聊天内容全是????????。原因是建库时没有指定 GBK 字符集或者导入 .sql 前没有 SET NAMES gbk。处理方式删除旧库按 4.1 的命令重新建库导入前先执行 SET NAMES gbk; 让当前会话的字符集和客户端保持一致。乱码一旦写入改连接串是救不回来的必须重建库重导数据。注意如果你连不上 MySQL 时看到「Host is not allowed to connect」这类错误是权限问题不是配置问题。在 MySQL 里执行GRANT ALL PRIVILEGES ON *.* TO root% IDENTIFIED BY 密码;后刷新权限再把服务端配置里的地址改为 127.0.0.1不要试图绕过去。6. 端到端验证与维护技巧从注册新账号到跨区存档的完整检查联调通过不代表真的能玩还需要做一次端到端验证。我习惯按玩家视角从头走一遍完整流程并且在每一步都回到数据库确认数据变化。只靠「看着好像进去了」来判断会漏掉存档读写这类看不见的故障。验证清单我固定如下注册新账号 → 登录 → 创建角色 → 进入游戏 → 打怪/捡物 → 下线重登 → 重启服务端 → 数据仍在。每一步的预期结果和数据库侧证据是绑在一起的。验证步骤操作动作预期结果注册账号登录器注册新用户名account 表新增一条记录status 为 0登录验证输入账号密码登录登录服日志打印登录成功进入选角色界面创建角色新建角色并命名role 表新增记录map_id 指向新手村地图进入游戏选择角色进入角色出现在新手村服务端日志无报错存档写入击杀一只怪后下线role 表经验值字段已更新重启验证重启全部服务端进程重新登录后角色等级、位置保持原样验证通过后日常维护的核心就一件事备份数据库。服务端源码坏了可以重新编译数据库丢了所有角色数据就没了。我的习惯是用 mysqldump 做定时备份每天凌晨一次保留最近七天。这个操作相当于给运维留后悔药真出现死锁把数据写坏了至少能回退到前一天的状态。# 备份到带时间戳的文件防止覆盖前一天的备份 mysqldump -uroot -p zt_game backup_$(date %Y%m%d_%H%M%S).sql参数说明mysqldump 的第一个参数是目标库名输出重定向到文件。命令替换符 $(date %Y%m%d_%H%M%S) 会把当前时间格式化成 20260601_153000 这样的字符串保证每次备份的文件名不同。Windows 下 Git Bash 支持这个语法纯 cmd 环境要用 %date% 变量替换写法略有差异。备份文件建议至少保留 3 份再清理不要只留最新一份因为最新的那份很可能就是坏的。这套东西跑通之后回头看服务端编译、数据库导入、客户端对接其实是一根链条而链条上最脆弱的三环就是版本一致性、数据库连接串和字符集。我的个人经验是每次改动前先给当前能跑的状态做个快照改配置只改一处验证通过后再动下一处。翻车翻得多了就明白大多数「莫名其妙跑不起来」都只是这三点中的某一点被遗漏了。希望这些踩坑记录能帮你少走几趟弯路早日把自己那份征途源码真正跑起来。本文还有配套的精品资源点击获取