前言游戏服务端线上故障 90% 都有标准化的定位路径和成熟修复方案，我们基于 Skynet 框架开发的游戏服务来说，绝大多数故障都源于 Actor 模型特性误用、Lua 协程调度踩坑、服务隔离设计缺陷，以及全行业通用的缓存数据不一致、消息队列积压、数据库打满等核心痛点。本手册全为线上实战沉淀，无空泛理论，严格遵循「问题前置→排查 SOP→落地方案→避坑指南」的逻辑，拿来就能用。一、线上故障排查核心前置原则（保命准则）Skynet 框架基于 Actor 模型实现了服务隔离，游戏服务端又对玩家实时体验有极致要求，所有线上排查动作必须先遵守以下 4 条准则，避免小问题酿成全服事故：先止损，再定位：优先保障玩家核心体验，能通过降级、切流、重启单服务快速恢复的，先做止损操作，再回头定位根因，绝不死磕根因拉长故障时长。先保留现场，再操作：非必要不重启进程，服务一旦重启，协程栈、内存快照、消息队列积压现场、CPU 占用现场会全部丢失，根因大概率无法复现。最小化操作原则：线上环境只做排查和必要的止损操作，禁止在线上改代码、加调试逻辑、临时写热更补丁，避免引发二次故障。可观测先行，不盲目登机器：先看监控大盘、错误日志、服务状态，缩小故障范围，再针对性登机器排查，绝不盲目敲命令浪费黄金排查时间。二、Skynet 框架专属高频故障排查与修复故障 1：单个服务 CPU 100%，其余服务完全正常可能出现的问题（故障现象）监控大盘显示单进程整体 CPU 拉满，细分到服务维度，仅单个服务 CPU 占用 99%+，其余服务 CPU 占用完全正常玩家对应功能完全卡顿 / 无响应，其余游戏功能一切正常异常服务的业务日志停止刷新，无新增报错信息该故障高频出现在玩家数据服务、战斗计算服务、AI 逻辑服务等高频计算类服务中标准化 SOP第一步：通过 Skynet 内置 console 控制台，锁定异常服务-- 进入skynet console控制台./3rd/lua/lua service/console.lua-- 执行stat指令，查看所有服务的CPU占用，记录异常服务的地址和名称stat第二步：抓取异常服务的协程栈，定位卡死代码位置-- 查看目标服务当前正在执行的协程栈，service_addr为上一步查到的异常服务地址debug.debug(service_addr)第三步：确认异常服务的消息队列状态，排查是否存在消息积压-- 执行list指令，查看所有服务的消息队列长度，确认异常服务是否存在队列持续暴涨list第四步：结合协程栈与业务代码，定位最终根因根因分析、修复方案与线上避坑指南核心根因修复方案线上避坑指南主协程出现无阻塞死循环，while true 循环内未加协程让出逻辑，协程始终占用调度权，其余消息无法被处理1. 紧急止损：给异常服务发送退出信号，重启对应单服务，快速恢复业务；2. 根治：所有循环逻辑必须增加协程让出操作，哪怕是 skynet.sleep (0)，给调度器留出切换空间绝对禁止在 Skynet 主协程中编写无任何阻塞操作的死循环，哪怕是临时测试代码，严禁带上线上