【框架设计】称号系统：称号佩戴与属性叠加的结算顺序

实战应用：用在哪里

称号既是荣誉展示也是属性来源，传奇引擎里称号动辄几十个，叠加规则一旦混乱就会属性膨胀。设计核心只有一条：属性结算永远从全量称号表重建，禁止逐个累加。荣誉感靠稀有度与全服播报撑起来，属性只是顺带的甜头。

称号数据与结算

local TITLES = {
    [3001] = { name = "初入玛法", atk = 10,  cond = "reach_lv_30" },
    [3002] = { name = "沙城功臣", hp  = 500, cond = "win_siege" },
}
function Title.recalc(plr)
    local atk, hp = 0, 0
    for _, tid in ipairs(plr.ownedTitles or {}) do
        local def = TITLES[tid]
        if def then atk = atk + (def.atk or 0); hp = hp + (def.hp or 0) end
    end
    plr.titleAtk, plr.titleHp = atk, hp
end

佩戴只影响头顶显示，不影响属性；拥有即生效，规则一句话能讲清，客服培训零成本。recalc 在获得称号、登录、转生三个时机触发，全量重建即使持有上百称号也在微秒级完成，性能无忧。

发放与展示

function Title.grant(plr, tid)
    for _, t in ipairs(plr.ownedTitles or {}) do
        if t == tid then return false end
    end
    table.insert(plr.ownedTitles, tid)
    Title.recalc(plr)
    QF_SendCenterTip(plr, "获得称号：" .. TITLES[tid].name)
    return true
end

发放前查重防止重复入库，全服公告只播稀有称号，普通称号静默入库。称号来源覆盖任务、活动、排行与付费四条线，条件字段进配置由条件引擎统一判定，新增称号只加配置不改代码。头顶称号用客户端 SL 接口绘制，字号与颜色随称号品质区分，图鉴界面用 GUI:Text_Create 逐行列出属性明细与获取途径。

验证与监控

称号属性总和每天与角色总属性抽样核对，差值超过 5 点上报数值组排查。

踩坑记录

最贵的一次教训是发放接口没做查重，活动补发时 1000 名玩家每人拿到两份称号，属性也跟着翻倍，回档还是补偿讨论了一晚上。查重改成拥有即跳过后，补发接口反而依赖这份幂等变得安全。头顶称号的字号早期不随品质变化，有人拿基础称号冒充稀有称号在主城招摇，后来给稀有档加了专属描边与光效，视觉上的辨识度比数值更能说明身份。多角色数据的称号同步曾经遗漏，主号拥有的称号在副号的图鉴里查不到，图鉴接口改为账号维度聚合后统一。发放渠道的埋点按任务、活动、付费三类标注，哪条线发出去的称号带来更高的在线提升，报表一目了然，称号系统的迭代方向因此始终有数据背书。多角色数据的称号同步曾经遗漏，主号拥有的称号在副号的图鉴里查不到，图鉴接口改为账号维度聚合后统一。发放渠道的埋点按任务、活动、付费三类标注，哪条线发出去的称号带来更高的在线提升，报表一目了然，称号系统的迭代方向因此始终有数据背书。

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