【界面UI】时装系统：外观与属性的分离存储方案

实战应用：用在哪里

时装卖的是外观，属性只是附赠。传奇引擎里外观资源走客户端展示层，属性走后端属性表，两套数据分开存储：时装过期外观立刻失效，属性结算却要等整点重算，混在一起就会出现过期时装还挂着属性的事故，玩家截图一到客服手里就是大事故。

数据分离

Fashion.slots = { body = 0, weapon = 0, wing = 0 }
function Fashion.wear(plr, slot, fid)
    local def = FASHION_DEF[fid]
    if not def or def.slot ~= slot then return false end
    if not QF_HasItem(plr, fid) then return false end
    plr.fashion[slot] = fid
    QF_PushAppearance(plr, slot, fid)
    return true
end

plr.fashion 只存外观位，QF_PushAppearance 下发外观变更；属性表另存每件时装的加成，由定时重算统一合并。同一槽位穿新装自动顶替旧装，旧装外观不丢失，衣柜里随时换回。

过期处理

function Fashion.sweep(now)
    for _, plr in ipairs(onlinePlayers) do
        for slot, fid in pairs(plr.fashion) do
            local def = FASHION_DEF[fid]
            if def.expireAt and def.expireAt <= now then
                plr.fashion[slot] = 0
                QF_PushAppearance(plr, slot, 0)
            end
        end
    end
end

每分钟扫描一次过期时装，外观与属性同拍失效，扫描开销在毫秒级。限时时装到期前 24 小时客户端弹窗提醒续费，续费继承已有时效不重新计时。永久时装与限时时装用同一张配置表区分，expireAt 为空即永久。时装柜界面用 GUI:Text_Create 渲染剩余天数，快到期的条目红字提示，试穿预览走 SL 外观接口，预览态不落库不占包裹。

验证与监控

过期扫描每轮记录失效件数，与到期配置比对，漏失效一件即告警。

踩坑记录

过期扫描最早挂在整点任务里，玩家卡着到期前几十秒截图，投诉属性还没掉，扫描粒度从小时级改成分钟级才堵住。外观与属性分表的初衷正是这类事故：属性重算有天然延迟，外观可以即时切，两边的时间差必须在界面上诚实展示已过期待重算，藏着的延迟迟早变成工单。续费继承时效的设计也救过口碑，续费不清零让老玩家的长期投入有安全感。外观资源按品质分层加载，入场动画只给高品质时装播放，低端机型的进城加载时间没有因为时装系统变长。试穿间与衣柜的交互做过一轮可用性测试，玩家最反感的是试穿后找不到购买入口，入口跟随试穿面板常驻是那轮测试的直接产出。时装的退款与赠送场景也走同一套分离数据，外观迁移属性重算，两个动作一个事务。外观资源按品质分层加载，入场动画只给高品质时装播放，低端机型的进城加载时间没有因为时装系统变长。试穿间与衣柜的交互做过一轮可用性测试，玩家最反感的是试穿后找不到购买入口，入口跟随试穿面板常驻是那轮测试的直接产出。时装的退款与赠送场景也走同一套分离数据，外观迁移属性重算，两个动作一个事务。

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