【实战案例】行会解散的数据清理：引用链的批量回收

实战应用：用在哪里

行会解散不是删一行记录：成员的行会归属、仓库的冻结物品、申请中的战报、频道的历史消息，十几张表里都挂着这个行会的 ID。一次解散漏清一张表，就是一个长期的数据幽灵，本案例是那次排查与修复的完整还原。

事故的发现

-- 巡检脚本的异常报告
function Inspection.guildOrphan()
    local members = QF_LoadAllPlayers()
    local orphans = {}
    for _, p in ipairs(members) do
        if p.guildId and not GuildMgr.exists(p.guildId) then
            orphans[#orphans + 1] = { userId = p.userId, guildId = p.guildId }
        end
    end
    return orphans
end

巡检脚本发现 137 名玩家的行会归属指向已不存在的行会 ID——这些玩家在三个解散的行会里。追溯根因：解散流程只删了行会主表与成员表，行会仓库、基金流水、行会任务进度三张表没有清理，孤儿数据在后续的行会重新创建时发生了串数据。

修复与流程补全

function GuildMgr.dissolveComplete(guildId)
    GuildMgr.clearMembers(guildId)
    RepoRepo.purge(guildId)
    FundLog.archive(guildId)
    GuildTask.purge(guildId)
    GuildChat.purge(guildId)
    QF_SetFlag("guild_dead_" .. guildId)
    QF_LogDissolve(guildId, os.time())
end

修复版的解散流程六张表逐个清理：成员归属清空、仓库物品邮件退回、基金流水归档、任务进度清除、频道历史销毁、解散标志置位。清理的顺序有讲究：先发玩家的物品退回邮件，再清仓库，末了删归属，顺序颠倒会让邮件的系统校验失败。三个受害行会的 137 名玩家逐一核对补偿，行会基金按流水退还。

验证与监控

孤儿数据巡检从每周一次改为每日一次，巡检的零结果连续 30 天才算流程修复可信。

踩坑记录

清理脚本的第一次执行漏了申请中的行会战报这张表，战报的行会名显示为乱码 ID，清单的完整性靠的是全库搜索行会 ID 字段而不是经验回忆。补偿的邮件曾经发重，幂等标记的缺失让 12 名玩家收到两份，补偿发放的幂等键从此成为标配。

上线要点

解散流程的每张关联表进文档维护，新表上线必须在解散清单登记。解散的预览界面给会长展示将被清理的数据清单，知情同意后再执行。孤儿巡检的告警直连值班，数据幽灵的存活时间越长，修复的代价越大。

本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付，内容以官方知识库与真实项目为出处，按版本持续修订。