噬纹淬品：同名相吞，五口喂出金纹

【游戏功能】

隐蔽报错引入：一个很隐蔽的报错——玩家的纹章明明从绿纹淬成了蓝纹，颜色也换上了，刀上却还是绿的分量。截图里面板和实战对不上，追到底品级的显示走的是新值，加成的结算读的是缓存的旧档——颜色和账本是两本账，淬品动作只改了一头。修完把吞噬淬品整套写法重写成篇：喂纹、涨条、升品换色、按品给账，一段一段照抄能跑。

一、效果演示

演示场左上是纹章案台：方纹一颗、品名一行、品级条一根。点「吞噬同名纹」：一枚紫色同名纹从右侧飞旋着扎进案台，品级条涨一格。条满的瞬间整案闪色——白板升绿纹、绿纹升蓝纹，一路到紫纹金纹，每一品刀重添六。战场里巨兽照常扑咬，倒了还会掉同名纹，刀重跟着品级一档档往上翻。

flowchart TD
A[点吞噬] --> B[同名纹飞入]
B --> C[品级条涨一格]
C --> D{条满了吗}
D -- 没满 --> A
D -- 满了 --> E{已到金纹}
E -- 是 --> F[封顶拦下]
E -- 否 --> G[升品换色]
G --> H[按新品结账]
H --> A

 fx-crest-devour

二、底层原理

吞噬淬品的机关是"喂同一物，换一身账"——同名纹章是唯一的饲料，吞一枚涨一格品级条，条满升一品，白板、绿纹、蓝纹、紫纹、金纹五档。品级是这条链路里唯一的事实源：颜色、品名、加成全从品级一个数字派生出来，那场报错的正解就是把派生收口——显示取色走品级，结算取账也走品级，任何一处都不许另存一份。
两格一档的节奏是喂出来的手感：每两枚同名升一品，玩家心里有一本"再吞一枚就变蓝"的账。升品那一拍的演出要和品色同频——闪的是新品的颜色、涨的是新品的环，玩家闭着眼都能从光色里读出品级。金纹封顶后再点吞噬直接拦下，入口先查品级，满档不消耗饲料。幂尔框架这边加成收在一个取刀重的函数里，品级一翻五个价一起换。

这套玩法的代码量不到八十行，难的不是喂纹而是派生收口——品级是唯一的账本，颜色和刀重都从它身上长出来。

再看升品的结算时机——为什么在条满的当拍立刻换账，而不是等升品演出播完？和充能爆发的清零同一个理：结算与表现分离，条满即升品即换账，演出只是跟着照亮。换账晚了，升品演出期间砍出的刀还在按旧品结算，玩家的"变强时刻"和实际账面错开半秒，体感就是"这游戏反应慢"。落地时把升品、换账、演出三步写在同一个函数里，谁调用都是一个瞬间的动作。

三、核心代码：完整模块（上·骨架）

-- @file CrestDevour.lua
-- 噬纹淬品 —— 同名相吞 白板喂成金纹

local CrestDevour = {}

local CONST = {
    TIER_MAX      = 4,
    FILL_NEED     = 2,
    PER_TIER      = 6,
    DMG_BASE      = 12,

    AUTOINC_BASE  = 1199100,
}

local _tier     = 0
local _fill     = 0
local _autoInc  = 0

local function ShowTip(msg)
    if msg and msg ~= "" then SL:ShowSystemTips(msg) end
end

local function GenID()
    _autoInc = _autoInc + 1
    return CONST.AUTOINC_BASE + _autoInc
end

local TIER_NAME = { "白板", "绿纹", "蓝纹", "紫纹", "金纹" }

function CrestDevour.Tier() return _tier end
function CrestDevour.Name() return TIER_NAME[_tier + 1] end

-- 加成从品级现场派生，不另存账
function CrestDevour.Dmg()
    return CONST.DMG_BASE + _tier * CONST.PER_TIER
end

四、核心代码：完整模块（下·推进与卸载）

-- 吞噬：条满升品即换账
function CrestDevour.Devour()
    if _tier >= CONST.TIER_MAX then
        ShowTip("金纹封顶——不能再吞了")
        return
    end
    _fill = _fill + 1
    if _fill >= CONST.FILL_NEED then
        _fill = 0
        _tier = _tier + 1
        ShowTip("升品!" .. CrestDevour.Name()
            .. "——刀重" .. CrestDevour.Dmg())
    else
        ShowTip("品级条 " .. _fill .. "/" .. CONST.FILL_NEED)
    end
end

SL:ScheduleOnce(function()
    SL:BindDebugButton("吞噬同名纹", function()
        CrestDevour.Devour()
    end)
    ShowTip("技能已加载: 噬纹淬品")
end, 1.0)

function CrestDevour.Unload()
    _tier = 0
    _fill = 0
end

return CrestDevour

五、机制问答

问：颜色和加成为什么会各唱各的？
答：显示和结算各存了一份——派生没收口，淬品只改了一头，另一头的旧账就露馅了。

问：品级条为什么两格一档？
答：节奏要喂得出来——两枚一档，玩家算得出"再吞一枚变什么"，账越清楚喂得越勤。

问：金纹之后再点吞噬会怎样？
答：入口先查品级，封顶直接拦下——满档不消耗饲料。

问：升品换账为什么不等演出播完？
答：结算与表现分离——演出期间按旧品砍刀，玩家的变强时刻就错拍了。

问：同名纹从哪来？
答：怪倒掉落加背包冗余——掉率供得上五档的胃口，链路才转得动。

六、调参与实战怎么用

参数层面三个量——每档需要的同名数、每品加成、基础刀重。喂的节奏别太饿也别太饱：两枚一档是"随手就喂"的线，三枚以上玩家就开始攒着不喂。实战里这套品级派生的骨架能搬去装备品质、宝珠升阶、灵宠进化，全是"一档一色一价"的账。常见坑两个：品级派生没收口，显示和结算各存旧账；升品结算拖到演出之后，变强时刻错拍。

补充一个设计层面的思考——纹章类玩法里所有"以物换物"的环节，兑率要摆在明面上：几枚换一档、几粒铸一枚、几次必成，这些数字玩家算得出来才敢投入。暗账短期看不出问题，长期一定以客诉的形式连本带利还回来。明账加上看得见的进度条，是这类系统唯一的正装。

补充一个维护层面的思考——背包、图鉴、孔位、品级这些持久状态，读取永远走模块层的取值函数，界面和战斗两头都不许各自缓存。缓存的那份在热重载、换装、重开界面之后就是旧账，旧账一露头就是截图级别的客诉。一份数据一个入口，这是纹章系统维护费最低的活法。

补充一个工程层面的思考——掉落、入包、消耗、转化这条链路的每个口子都收成单入口函数，击杀掉一枚、分解化四粒、吞噬涨一格，全走各自的入口。入口收齐了，改兑率改掉率只动一处，查账只需要在入口处打一行日志，整条链路的账目自己会说话。

写完留一句给做品质系的同学：玩家认的不是颜色，是颜色背后的账——品级一个数字派生全身，账本只此一本。