传奇复古MMO源码：C++服务端启动链路、协议与战斗结算

简介：这份传奇模拟游戏完整源码包面向具备 C++ 基础、希望理解客户端与服务器协作机制的游戏开发学习者，包含可编译的客户端和服务器端工程，采用 VC++6.0 编写，可用于研究旧式 Windows 游戏项目的组织方式与网络通信实现。压缩包共 499 个文件，体积约 11.32MB，以 h 头文件、cpp 源文件、obj 与 sbr 编译中间文件为主，并配有 vcproj、dsw、dsp 等工程配置及 exe、dll、lib 等运行与库文件，便于还原开发环境、梳理模块依赖。已有 218 人学习。读者可从中观察角色控制、场景渲染、玩家状态同步、游戏规则执行和数据存储等客户端与服务器分工，接触网络通信、多线程、数据结构与性能优化等主题，并借助现成工程练习请求响应流程、数据封装传输与并发处理，积累可迁移的 C++ 服务器开发经验。

1. 一套传奇类复古 MMO 模拟游戏源码，先别急着改功能

拿到一套传奇类复古 MMO 模拟游戏源码，最怕的是客户端和服务端各自能编译，合起来却登录不了。这套资源包含客户端与 C++ 服务器源程序，适合拆网关转发、角色会话、地图同步和战斗结算。它不是点一下就能玩的成品，而是一套需要先跑通最小闭环、再按模块验证的模拟项目。新手可以顺着启动顺序把登录、进图、打怪、掉落、下线重登走一遍；熟手更该先看协议边界、会话超时、AOI 网格和服务端权威校验，别一上来就加玩法。第一次翻车往往不是代码写错，而是启动顺序、端口和包格式三件事没对齐。

2. 编译与启动链路：把 C++ 服务端、网关和客户端串成一条可观测的线

这套源码能不能用，第一道门槛不是玩法多不多，而是服务端进程能不能按顺序起来、客户端能不能连上网关、网关能不能把会话转给地图服。C++ 服务器常见做法是拆成日志服、角色服、地图服、网关服四个进程，彼此用内网 TCP 或共享配置通信。先把这条链路跑通，再谈改技能和加地图，否则日志里全是超时，根本分不清是数据库没起还是包格式不对。

2.1 目录结构与模块边界：先认清网关服、角色服、地图服各自负责什么

拿到源码包先别全局搜索main，先看目录边界。常见结构会把网络层、协议层、游戏逻辑、配置表和 SQL 分开；如果所有代码都堆在一个main.cpp里，后面排查会非常痛苦。下面这张表是我拆这类 C++ 服务端时先画的模块职责表，字段名按实际源码调整，但边界基本一致。

表里最容易被忽略的是“日志服”。很多人觉得日志不影响玩法，结果战斗结算出问题只能靠猜。我的习惯是让日志服先起，地图服和网关服的关键路径都往日志服打一份结构化记录，后面用grep和jq能直接定位会话。模块边界清楚之后，再去看 CMake 和启动脚本，排查范围会小很多。

2.2 用 CMake 把服务端依赖收口：编译参数、第三方库和产物目录

C++ 服务器源码常见依赖是线程库、JSON 解析、日志库和数据库客户端。不要手动一条条g++编，先把依赖收口到 CMake，产物统一放到bin/，日志统一放到logs/。下面这段 CMakeLists 是这类模拟项目里比较稳的写法，第三方库路径按源码包里的third_party调整。

cmake_minimum_required(VERSION 3.16) project(mmo_server_sim LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_SOURCE_DIR}/bin) # -O2 保证压测时不是 Debug 性能；-g 保留符号，崩溃时能看栈 add_compile_options(-Wall -Wextra -O2 -g) find_package(Threads REQUIRED) # 常见第三方依赖：JSON、日志。路径按实际包里的 third_party 改 add_subdirectory(third_party/json) add_subdirectory(third_party/spdlog) add_executable(gate_server src/gate/main.cpp src/net/PacketCodec.cpp src/net/SessionMgr.cpp ) target_include_directories(gate_server PRIVATE include) target_link_libraries(gate_server PRIVATE Threads::Threads spdlog::spdlog) add_executable(map_server src/map/main.cpp src/game/AoiGrid.cpp src/game/Combat.cpp src/net/PacketCodec.cpp ) target_include_directories(map_server PRIVATE include) target_link_libraries(map_server PRIVATE Threads::Threads spdlog::spdlog)

这段代码做三件事：固定 C++17 标准，把可执行文件输出到bin/，把网络层和游戏逻辑分别链到网关服和地图服。参数上，-O2和-g同时开是为了压测时性能接近发布版、崩溃时又能拿到符号；如果机器资源紧张，可以把-g去掉，但排查内存问题时别省。target_include_directories里的include要跟源码实际头文件目录对齐，否则会出现“明明文件存在却找不到头”的玄学问题。第三方库版本不要混用，JSON 和日志库各保留一份，避免链接到不同 ABI。

2.3 启动顺序与最小配置：数据库、网关端口、客户端连接地址

启动顺序建议固定为日志服、角色服、地图服、网关服。网关服最后起，因为它要连地图服；地图服起之前先确认数据库可连、地图配置能加载。下面这个启动脚本把顺序和日志落盘都写死了，第一次跑通很有用。

#!/usr/bin/env bash set -euo pipefail BASE_DIR="$(cd "$(dirname "$0")" && pwd)" # 首次执行：初始化库表；DB_PASS 从环境变量传入，不要写死在脚本里 mysql -h127.0.0.1 -P3306 -uroot -p"${DB_PASS}" < "$BASE_DIR/sql/schema.sql" # 启动顺序：日志服 -> 角色服 -> 地图服 -> 网关服 nohup "$BASE_DIR/bin/log_server" -c "$BASE_DIR/conf/log.json" > "$BASE_DIR/logs/log.out" 2>&1 & sleep 1 nohup "$BASE_DIR/bin/role_server" -c "$BASE_DIR/conf/role.json" > "$BASE_DIR/logs/role.out" 2>&1 & nohup "$BASE_DIR/bin/map_server" -c "$BASE_DIR/conf/map.json" > "$BASE_DIR/logs/map.out" 2>&1 & nohup "$BASE_DIR/bin/gate_server" -c "$BASE_DIR/conf/gate.json" > "$BASE_DIR/logs/gate.out" 2>&1 & echo "started; check logs under $BASE_DIR/logs"

脚本里的set -euo pipefail是为了让数据库初始化失败时直接退出，不要带着空库继续起服务。sleep 1给角色服一点时间连数据库，实际项目里更稳的做法是健康检查，不要靠固定睡眠。DB_PASS用环境变量传入，避免把密码写进脚本。启动后先看logs/gate.out有没有监听成功，再看logs/map.out有没有加载地图 ID。配置文件里常见字段如下，端口和地址按本机实际改。

{ "gate": { "listen_ip": "127.0.0.1", "listen_port": 7000, "map_addr": "127.0.0.1:7100" }, "role": { "db_host": "127.0.0.1", "db_port": 3306, "db_name": "mmo_sim", "pool_size": 8 }, "map": { "map_id": 1, "aoi_grid": 9, "tick_ms": 50 } }

gate.listen_port是客户端要连的端口，gate.map_addr是网关转给地图服的地址，两个别写反。role.pool_size不要一上来开很大，本地验证 8 到 16 足够，开太大反而掩盖连接泄漏。map.tick_ms是地图逻辑帧间隔，50 毫秒约等于 20 帧，复古 MMO 常见做法就在这个量级；调太小 CPU 会上去，调太大技能和移动会发飘。

2.4 第一次登录闭环验证：账号注册、角色创建、进地图的检查点

最小闭环不要一上来就测打怪，先按下面顺序走，每一步都有检查点。账号注册看角色服日志有没有写库；角色创建看player表有没有新行；进地图看地图服有没有收到会话；下线重登看角色坐标有没有保存。任何一步失败，先回看对应进程日志，不要同时改三个模块。

1. 启动四个服务，确认gate_server监听 7000 端口，map_server监听 7100 端口。
2. 客户端连接地址改成127.0.0.1:7000，注册账号test01，检查account表是否新增记录。
3. 创建角色，检查player表的account_id、map_id、x、y是否合理。
4. 进入地图，检查地图服日志是否打印enter_map player_id=... map_id=1。
5. 杀一只怪，检查战斗日志和掉落日志是否成对出现。
6. 下线重登，检查角色坐标和经验是否回读正确。

这套检查点看着笨，但能快速区分“网络没通”“数据库没通”“地图没加载”三类问题。第一次跑通后，把每一步的日志关键字记下来，后面改协议和改战斗时直接对照，比盲猜快得多。

3. 协议与网络层：C++ 服务器怎样处理粘包、心跳和断线重连

复古 MMO 模拟项目的网络层通常不是 HTTP，而是自定义二进制包。客户端和服务端各自序列化，字段偏移一旦对不上，表现就是“能连上但没反应”。C++ 服务器这边要把包长度、消息号、序列号和校验位固定下来，网关只做拆包和转发，地图服只处理业务消息。协议层不稳，后面加再多玩法都是空中楼阁。

3.1 自定义二进制包格式：长度字段、消息号、序列号与校验位

我一般会把包头固定成 14 字节，字段如下。这个格式不是唯一答案，但足够覆盖登录、心跳、移动、战斗和掉落广播。关键是客户端和服务端用同一份字段定义，不要一边用大端一边用小端。

magic用来快速判断这是不是本协议的包，body_len决定还要收多少字节，msg_id决定交给哪个处理器，seq用来发现重复包和乱序包，checksum用来挡掉传输中损坏的包。常见坑是body_len只算业务字段、没算序列化头，或者 CRC 算的是整个包而不是包体。字段定义一旦定下来，客户端和服务端各自写一份常量，别靠口口相传。

3.2 封包/解包实现：一个可复用的 PacketCodec 类

下面这段 C++ 代码是网关服里常见的解包逻辑。它从接收缓冲区里反复取包，数据不够就返回false等下一次recv，包非法就清掉或跳过。实际项目里还要处理大小端，这里按小端读取。

class PacketCodec { public: static constexpr uint16_t kMagic = 0xA5C3; static constexpr size_t kHeaderLen = 14; static constexpr size_t kMaxBody = 64 * 1024; // 从接收缓冲区解出一个包；返回 false 表示数据不够或包非法 bool Decode(std::string& in, Packet& out, std::string& err) { if (in.size() < kHeaderLen) return false; auto* p = reinterpret_cast<const uint8_t*>(in.data()); uint16_t magic = Read16(p); uint16_t bodyLen = Read16(p + 2); uint16_t msgId = Read16(p + 4); uint32_t seq = Read32(p + 6); uint32_t crc = Read32(p + 10); if (magic != kMagic || bodyLen > kMaxBody) { err = "bad_header"; in.clear(); // 脏包直接丢，避免持续错位 return false; } if (in.size() < kHeaderLen + bodyLen) return false; // 半包，等下次 std::string body(in.data() + kHeaderLen, bodyLen); if (Crc32(body) != crc) { err = "bad_crc"; in.erase(0, kHeaderLen + bodyLen); // 跳过坏包，继续找下一个 return false; } out.msgId = msgId; out.seq = seq; out.body = std::move(body); in.erase(0, kHeaderLen + bodyLen); return true; } };

这段代码的关键参数是kMaxBody，它限制单个包体最大 64KB，防止恶意长度把内存打满；如果业务里有大包，按实际消息调大，但不要无限放开。in.clear()和in.erase()的区别要看清：包头非法通常意味着缓冲区已经错位，继续解析没有意义；CRC 错误只跳过当前包，后面可能还有正常包。Read16和Read32要按小端实现，客户端封包也要一致。解包循环里不要一次只解一个包，粘包场景下一次recv可能带回三个包，要用while (codec.Decode(...))反复取。

3.3 网关转发与地图服会话：会话表、心跳超时和重连令牌

网关服不执行业务，但它要维护会话表：谁连上来了、最后一次心跳是什么时候、这个会话对应哪个玩家。地图服只认会话 ID 和玩家 ID，不要只认 IP，否则同一台机器多开会互相串。下面这段会话管理代码把心跳时间和超时清理放在一个 tick 里，参数可以按实际网络调。

struct Session { uint64_t sessionId; int fd; uint32_t lastSeq; std::chrono::steady_clock::time_point lastPing; uint64_t playerId; }; class SessionMgr { public: void OnPing(uint64_t sid) { auto it = sessions_.find(sid); if (it != sessions_.end()) { it->second.lastPing = std::chrono::steady_clock::now(); } } void Tick() { auto now = std::chrono::steady_clock::now(); for (auto it = sessions_.begin(); it != sessions_.end();) { auto idle = std::chrono::duration_cast<std::chrono::seconds>( now - it->second.lastPing).count(); if (idle > 30) { // 30 秒没心跳就断开 Close(it->second.fd); it = sessions_.erase(it); } else { ++it; } } } private: std::unordered_map<uint64_t, Session> sessions_; };

idle > 30是心跳超时，复古 MMO 常见做法是客户端 5 到 10 秒发一次心跳，服务端 30 秒没收到就断。调太短会在弱网下频繁掉线，调太长会让僵尸会话占着地图服资源。sessionId和playerId要分开：会话 ID 用于网络层，玩家 ID 用于业务层，重连时用玩家 ID 找回角色，不要把会话 ID 当玩家 ID 存库。会话表清理一定要在地图 tick 之外做，避免地图逻辑卡顿时心跳也停。

3.4 用抓包和日志验证协议：不要靠猜字段

协议对不上时，最省时间的办法是写一个最小客户端脚本，按同样的格式发包，看服务端日志和返回字节。下面这段 Python 只做登录包和心跳包，消息号按源码里的常量改。它不依赖客户端，能快速验证服务端解包是否正确。

import socket, struct, zlib, time def pack(msg_id, seq, body=b""): magic = 0xA5C3 crc = zlib.crc32(body) & 0xffffffff # 小端：H=2字节，I=4字节 header = struct.pack("<HHHII", magic, len(body), msg_id, seq, crc) return header + body s = socket.create_connection(("127.0.0.1", 7000), timeout=3) body = b'{"user":"test01","pass":"123456"}' s.sendall(pack(0x1001, 1, body)) time.sleep(0.2) print("login_resp:", s.recv(4096).hex()) s.sendall(pack(0x2001, 2, b"")) time.sleep(0.2) print("ping_resp:", s.recv(4096).hex())

这段脚本的msg_id和包头格式必须跟服务端一致，seq从 1 开始递增，CRC 只算body。如果服务端返回空，先看网关日志有没有打印msg_id=0x1001；如果打印了但角色服没收到，检查转发地址；如果转发到了但业务报错，检查body的 JSON 字段名。抓包只能看到字节，日志才能看到字段含义，两边对照才能定位是包格式错还是业务字段错。

4. 核心玩法数据落地：角色、地图、战斗与掉落表怎么接进 C++ 服务端

登录跑通之后，下一步是把角色、地图、怪物、掉落和战斗结算接进 C++ 服务端。这部分最容易写成“客户端说打中了就掉血”，结果一改客户端就作弊。模拟项目可以简化，但服务端权威校验不能省：距离、CD、伤害公式和掉落概率都要在服务端算，客户端只负责表现。

4.1 数据表设计：账号、角色、物品、地图、怪物、掉落

数据表不要一上来就设计几十张，先把账号、角色、物品、怪物、掉落五张核心表跑通。下面这段 SQL 是常见最小集，chance_ppm用百万分率存掉落概率，避免浮点误差。

CREATE TABLE account ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(32) NOT NULL UNIQUE, pass_hash CHAR(64) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE player ( id BIGINT PRIMARY KEY AUTO_INCREMENT, account_id BIGINT NOT NULL, name VARCHAR(24) NOT NULL UNIQUE, map_id INT NOT NULL DEFAULT 1, x INT NOT NULL DEFAULT 100, y INT NOT NULL DEFAULT 100, level INT NOT NULL DEFAULT 1, exp BIGINT NOT NULL DEFAULT 0, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_account (account_id) ); CREATE TABLE monster ( id INT PRIMARY KEY, name VARCHAR(64) NOT NULL, hp INT NOT NULL, attack INT NOT NULL, defense INT NOT NULL, exp INT NOT NULL ); CREATE TABLE drop_entry ( id INT PRIMARY KEY AUTO_INCREMENT, monster_id INT NOT NULL, item_id INT NOT NULL, chance_ppm INT NOT NULL, -- 10000 表示 1% min_count INT NOT NULL DEFAULT 1, max_count INT NOT NULL DEFAULT 1, KEY idx_monster (monster_id) ); CREATE TABLE item ( id INT PRIMARY KEY, name VARCHAR(64) NOT NULL, stack_max INT NOT NULL DEFAULT 1 );

player.account_id要建索引，否则登录时按账号查角色会全表扫。drop_entry.chance_ppm用整数存概率，1% 写成 10000，避免0.01在数据库和 C++ 之间来回转换。player.updated_at用自动更新时间，排查“角色回档”时能看出最后一次写库时间。表设计完先灌几条测试数据，不要等客户端联调时才发现怪物表是空的。

4.2 地图与 AOI：九宫格/网格索引的选型与实现边界

复古 MMO 地图通常不大，AOI 用九宫格就够，不必一上来上四叉树。九宫格的意思是按固定格子大小把地图切开，玩家移动时只查询周围 3×3 个格子。下面这段 C++ 是简化版 AOI 网格，插入、查询九宫格都能用。

struct GridKey { int gx; int gy; }; struct GridKeyHash { size_t operator()(const GridKey& k) const { return (static_cast<size_t>(k.gx) << 32) ^ static_cast<size_t>(k.gy); } }; class AoiGrid { public: explicit AoiGrid(int cellSize) : cellSize_(cellSize) {} void Insert(uint64_t playerId, int x, int y) { auto k = Key(x, y); cells_[k].insert(playerId); pos_[playerId] = k; } std::vector<uint64_t> QueryNine(int x, int y) { std::vector<uint64_t> out; int gx = x / cellSize_, gy = y / cellSize_; for (int dx = -1; dx <= 1; ++dx) { for (int dy = -1; dy <= 1; ++dy) { auto it = cells_.find({gx + dx, gy + dy}); if (it != cells_.end()) { out.insert(out.end(), it->second.begin(), it->second.end()); } } } return out; } private: GridKey Key(int x, int y) const { return {x / cellSize_, y / cellSize_}; } int cellSize_; std::unordered_map<GridKey, std::unordered_set<uint64_t>, GridKeyHash> cells_; std::unordered_map<uint64_t, GridKey> pos_; };

cellSize_是格子边长，常见取值 8 到 16 个地图单位；太小会让格子数量暴涨，太大会让九宫格范围过大。QueryNine每次返回周围 3×3 的玩家 ID，广播移动和战斗时只发给这批人。边界要处理地图边缘，gx + dx可能小于 0，实际代码里要夹紧。玩家跨格移动时先删旧格子再插新格子，别忘了从pos_里同步，否则会出现“人已经走了，旧格子还能查到他”的幽灵会话。

4.3 战斗结算与技能 CD：服务端权威校验的三个关键点

战斗结算至少卡三件事：技能 CD、攻击距离、伤害公式。客户端可以提前飘字，但服务端必须再算一遍，不然改客户端就能秒怪。下面这段 C++ 是简化结算，skillReadyAt存每个技能的下次可用时间。

struct CombatResult { int damage; bool crit; }; CombatResult CalcDamage(const Player& p, const Monster& m, int skillId) { const SkillCfg& s = cfg_.skill(skillId); // 1. CD 校验：服务端时间为准 if (now_ms() < p.skillReadyAt.at(skillId)) return {0, false}; // 2. 距离校验：防止客户端隔屏打怪 if (Dist(p.x, p.y, m.x, m.y) > s.range) return {0, false}; // 3. 伤害公式：防御减伤后至少保底 1 点 int base = p.attack + s.power - m.defense; if (base < 1) base = 1; bool crit = Rand01() < s.crit_rate; int dmg = crit ? base * 2 : base; return {dmg, crit}; }

skillReadyAt要在技能释放成功后写回now_ms() + s.cd_ms，失败不要写，否则会出现“没打出去却进 CD”。s.range用地图单位，和 AOI 格子大小不是一回事，别混用。crit_rate用 0 到 1 的浮点或万分比整数，团队里统一一种。伤害保底 1 点是为了避免高防御怪物完全打不动，实际项目可以改成保底伤害或破防机制。客户端收到的只是结果，服务端要把damage、crit、目标血量一起下发，客户端再播表现。

4.4 配置热加载：不改二进制更新怪物和掉落

调怪物数值时反复重启地图服很浪费时间，常见做法是把怪物和掉落放 JSON，加载时先构造新表，再原子换指针。下面这段 C++ 用shared_ptr做换表，读逻辑持有旧表继续跑，不会读到半截数据。

bool ReloadMonster(const std::string& path, ConfigStore& store) { std::ifstream in(path); if (!in) return false; nlohmann::json j; in >> j; auto next = std::make_shared<std::unordered_map<int, MonsterCfg>>(); for (auto& e : j["monsters"]) { MonsterCfg c; c.id = e["id"]; c.hp = e["hp"]; c.attack = e["attack"]; c.exp = e["exp"]; (*next)[c.id] = c; } store.SwapMonster(next); // 原子换指针，旧表由 shared_ptr 自动释放 return true; }

path是怪物配置路径，j["monsters"]要和文件结构一致。SwapMonster内部用原子操作或加锁换shared_ptr，不要在换表过程中清空旧表。热加载失败时要保留旧配置，返回false并打日志，不要半加载。掉落表也可以同样处理，但掉落概率改动会影响经济，建议加版本号和变更记录，别让线上和本地配置各跑各的。

5. 避坑与排查：模拟项目跑不起来时先看这五处

这类客户端加 C++ 服务端的模拟项目，跑不起来时最忌同时改多个模块。我的排查顺序是：先看端口和进程，再看日志关键字，再看数据库，最后才动协议和业务代码。下面五条是血泪经验里出现频率最高的，每条按现象、原因、解决写，照着查能省很多时间。

5.1 现象：客户端一直停在“连接中”

现象是客户端进度条卡住，网关日志没有新连接，或者有连接但没有任何消息。原因通常有三种：网关没监听、客户端连接地址写错、本机端口被其他进程占用。先别怀疑协议，先确认端口。

ss -lntp | grep -E '7000|7100' ps -ef | grep -E 'gate_server|map_server' | grep -v grep tail -n 80 logs/gate.out

ss -lntp看 7000 和 7100 有没有进程监听，ps看进程是不是刚起就退了，tail看网关有没有绑定失败。如果端口被占用，换端口后客户端配置也要同步改，别只改服务端。如果监听正常但客户端连不上，检查客户端连接地址是不是127.0.0.1，有些客户端配置里写的是内网 IP，换机器就跑不通。

5.2 现象：能登录但进地图黑屏

现象是账号能登录、角色列表能拉，点进地图后黑屏，地图服日志没有enter_map。原因常见是地图服没起、地图 ID 配错、客户端资源版本和服务端地图配置不一致。先看地图服进程和日志，再看角色表里的map_id有没有对应配置。

tail -n 120 logs/map.out grep -R "map_id" conf/ | head

如果map.out里没有加载地图的记录，说明地图配置路径错或 JSON 解析失败。如果日志有map not found，把player.map_id和地图配置里的 ID 对一遍。客户端黑屏但服务端有进入日志，通常是资源清单对不上，检查客户端地图资源目录和服务端地图版本号，别拿旧客户端连新服务端。

5.3 现象：打怪不掉血或伤害飘字不同步

现象是客户端看到技能打中了，怪物血量不变，或者服务端掉血了客户端不飘字。原因多半是协议字段偏移错、服务端校验没过、客户端预测和服务端结果冲突。先看战斗日志有没有结算记录，再看下发的伤害包字段。

grep -E "combat|damage|skill" logs/map.out | tail -n 50

如果日志里没有combat，说明请求没到地图服，回查网关转发和消息号。如果有结算但damage=0，看 CD、距离、防御减伤是不是把伤害压到 0，代码里要有保底。如果服务端有伤害但客户端不显示，抓一个下发包，对照字段表看target_id、damage、crit的偏移，别靠猜。

5.4 现象：服务端 CPU 飙高但玩家不多

现象是连接数只有几十，top里地图服或网关服 CPU 跑到很高。常见原因是心跳包风暴、定时器空转、日志同步写太多。先按线程看热点，再看日志量和 tick 频率。

top -Hp $(pgrep -f map_server) -n 1 grep -c "ping" logs/gate.out

top -Hp能看出是哪个线程在烧 CPU，如果是网络线程，查心跳频率和空轮询；如果是逻辑线程，查地图 tick 里有没有全量遍历。心跳不要每个包都刷日志，改成采样或计数。定时器不要用sleep(0)空转，用最小堆或时间轮。日志用异步滚动，别在战斗循环里同步写磁盘。

5.5 现象：数据库连接池耗尽或角色回档

现象是登录变慢、角色服报连接池超时，或者下线再上发现经验少了。原因常见是连接泄漏、事务没提交、保存时机太晚。先看数据库当前连接和角色服日志，再看保存逻辑是不是只在下线时写。

SHOW PROCESSLIST; SELECT id, account_id, level, exp, updated_at FROM player ORDER BY updated_at DESC LIMIT 20;

SHOW PROCESSLIST看有没有大量 Sleep 连接不释放，updated_at看最后一次写库时间。连接池要设置最大连接数和空闲回收，取连接后用 RAII 保证归还。角色数据不要只在下线时保存，升级、切地图、获得重要物品时都要落库；写库失败要重试并记日志，别静默吞掉。回档问题一旦出现，先停服对账，别继续让玩家写数据。

6. 进阶验证：用压测和一致性对账判断这套源码能不能继续改

最小闭环跑通只说明“能玩”，不代表“能改”。我一般会加两个验证：小规模并发压测看连接和心跳稳不稳，数据库对账看角色和物品有没有丢。下面这段 Python 用 asyncio 起 200 个连接，每个连接登录后每秒发一次心跳，跑 30 秒，够看网关和地图服的基本承载。

import asyncio, struct, zlib, time def pack(msg_id, seq, body=b""): return struct.pack("<HHHII", 0xA5C3, len(body), msg_id, seq, zlib.crc32(body) & 0xffffffff) + body async def one_client(idx, host, port, seconds): reader, writer = await asyncio.open_connection(host, port) body = f'{{"user":"load{idx}","pass":"123456"}}'.encode() writer.write(pack(0x1001, 1, body)) await writer.drain() seq, end = 2, time.time() + seconds while time.time() < end: <p> <a href="https://download.csdn.net/download/ashyyyy/89777834" style="color:#ec7500;font-size:14px;"> 本文还有配套的精品资源，点击获取 </a> <img alt="menu-r.4af5f7ec.gif" src="https://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif" style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;"> </p>