上一篇主要聊了搭建环境和初步踩坑，这一篇开始进入“深水区”——后台管理、服务端逻辑梳理、前端子模块之间的调用关系、以及几个典型BUG案例。如果说第一篇是“把源码搬出来跑起来”，这一篇就是“摸清它的内脏和神经”。
我先从后台管理说起。
我最开始以为后台管理只是个配置面板，结果深入看代码发现，它其实是整个项目的“神经中枢”：用户数据、模块开关、统计报表全在这里。你发的那张后台截图（白底大表格）对我帮助巨大——它不仅能看到玩家在哪个模块，还能实时监控接口状态、同步数据库字段。
为了验证后台的可靠性，我写了个小测试脚本自动巡检接口：
const axios = require('axios');
async function checkAPI(moduleName) {
try {
const res = await axios.get(`http://127.0.0.1:3000/api/${moduleName}/status`);
console.log(`${moduleName} =>`, res.data.status);
} catch (err) {
console.error(`${moduleName}接口异常:`, err.message);
}
}
['moduleA','moduleB','moduleC'].forEach(m => checkAPI(m));
一键跑完就能知道哪些模块报错，省得每次点后台页面去看。
接下来是服务端逻辑。源码的后端主要用 Node.js，文件分三层：routes 放路由，controllers 放业务逻辑，models 放数据库操作。刚接手时我用“顺藤摸瓜”的方法：
- 先看
routes里暴露了哪些接口 - 再看对应的控制器文件
- 最后看
models里SQL怎么写
这样几天就摸清楚整个项目的数据流向。顺便建议在全局加一个错误中间件，防止崩溃：
app.use((err, req, res, next) => {
console.error('Error:', err.stack);
res.status(500).json({ error: 'Internal Server Error' });
});
有了这个兜底，前端就算调了个错接口，也不会直接把服务搞挂。
再说前端子模块之间的关系。CocosCreator的特点是Prefab化，模块多时如果不梳理清楚，很容易加载卡顿。我当时用了一张草图画出“模块调用关系”：大厅→模块A→模块B，哪些是同步加载，哪些是异步加载，一目了然。
在代码上，我用预加载和事件机制做了解耦：
cc.director.preloadScene("moduleA", function () {
console.log("moduleA loaded");
});
以及一个全局事件总线：
const EventBus = new cc.EventTarget();
EventBus.on('player-update', data => {
console.log('Player updated:', data);
});
EventBus.emit('player-update', {id:123,name:'test'});
大厅模块只管发事件，各个子模块各自监听，不用硬绑引用，这样后期维护起来舒服多了。
然后说几个典型BUG案例：
1. 后台数据不同步
我有一次发现后台显示用户初始值是0，但前端已经有数据。查了半天发现接口返回的字段名改了，后台没同步更新。改完接口后秒恢复。
2. 时间戳不统一
源码里有的用秒，有的用毫秒，导致排行榜乱排序。解决办法是在数据库和接口读写时统一转换：
let timestamp = Date.now(); //毫秒
// 如果接口需要秒
timestamp = Math.floor(timestamp / 1000);
3. 资源路径拼接错误
有的模块拼路径时少了斜杠，有的多了，部署时全404。我写了个全局函数：
function getAssetPath(fileName) {
return `${process.env.ASSET_PREFIX || '/assets/images/'}${fileName}`;
}
只要改环境变量就能全局换路径，省下无数坑。
4. Session混乱
源码默认后台和前端共用一个端口，Session容易串。我后来改成独立端口+Redis存Session：
const session = require('express-session');
const RedisStore = require('connect-redis')(session);
app.use(session({
store: new RedisStore({ host: '127.0.0.1', port: 6379 }),
secret: 'mysecret',
resave: false,
saveUninitialized: false
}));
一改就稳，再也没有登录错乱的问题。
除了这些BUG，我还加了日志和监控。大型项目光靠console.log不够，我用 winston 按日期切割日志：
const { createLogger, transports, format } = require('winston');
const logger = createLogger({
format: format.combine(format.timestamp(), format.json()),
transports: [
new transports.File({ filename: 'error.log', level: 'error' }),
new transports.File({ filename: 'combined.log' })
]
});
logger.info('服务启动成功');
结合 PM2 还能自动重启、集中收集日志。
最后说一点心态。折腾这种源码，最大陷阱就是“没跑通就改”。我现在习惯先在本地完整跑一遍、用后台看数据是否正常，再开始改功能。用Git做版本管理，每改一块提交一次，出问题能立刻回滚。
这一篇总结下来，后台和服务端的重点就是：
- 用后台当“体检仪”，多跑、多看
- 把Node.js路由、控制器、模型摸清楚
- 子模块用预加载+事件解耦
- BUG排查要有统一规范（时间戳、路径、Session）
- 日志和监控是救命稻草
- 改前一定要先跑通
下一篇我会聊前端UI重构、性能优化、模块拆分，以及深度二开的技巧，也会贴更复杂的代码，整个三部曲就完整闭环了。
转载请注明出处，仅限技术交流，禁止商用。
相关文章:
下载地址:
