每个东西都有专属座位：sceneGraph功能节点树

新接手引擎渲染层的人，打开场景会看到一锅粥：地图、角色、特效、血条、UI 全糊在一起。996 引擎的答案是把场景拆成一张"座位表"——scene/sceneGraph.lua 的 LoadGraph 函数，二十多行 getChildByTag 链，把每个功能节点按 tag 编号领了固定座位。今天讲完这张座位表，渲染顺序的所有玄学都会变成查表题。

这张表解决的根本问题是"渲染顺序的话语权"。没有座位表的引擎，渲染顺序取决于谁 addChild 得早、谁的 zOrder 数字大——两个业务系统各调各的 zOrder，一场"谁压谁"的军备竞赛就开始了，最后场景里的数字从 0 涨到 99999，谁也不敢动。座位表把顺序的决定权收归树结构：挂对位置永远赢，挂错位置永远输，没有第三种可能。顺序从博弈题变成查表题，这就是架构给确定性。

一、座位表：tag 链就是组织架构图

先看 LoadGraph 的原文节选，感受一下这种写法：

function sceneGraph:LoadGraph(fileName)
    local scene = requireExport(fileName).create()
    if nil == scene or nil == scene.root then
        return -1
    end
    local rootNode = scene.root
    self.mC2dxScene = cc.Scene:create()
    self.mC2dxScene:addChild(rootNode, 1, 9999)

    -- 每个功能节点按 tag 领座位，链式 getChildByTag 层层深入
    self.mFunctionalSceneNode[global.MMO.NODE_ROOT]         = rootNode
    self.mFunctionalSceneNode[global.MMO.NODE_GAME_WORLD]   = rootNode:getChildByTag(10023)
    self.mFunctionalSceneNode[global.MMO.NODE_MAP_SLICE]    = rootNode:getChildByTag(10023):getChildByTag(10003):getChildByTag(10006)
    self.mFunctionalSceneNode[global.MMO.NODE_ACTOR_SHADOW] = rootNode:getChildByTag(10023):getChildByTag(10004):getChildByTag(10007)
    self.mFunctionalSceneNode[global.MMO.NODE_ACTOR_SPRITE] = rootNode:getChildByTag(10023):getChildByTag(10004):getChildByTag(10008)
    self.mFunctionalSceneNode[global.MMO.NODE_ACTOR_SFX_FRONT] = rootNode:getChildByTag(10023):getChildByTag(10004):getChildByTag(10010)
    self.mFunctionalSceneNode[global.MMO.NODE_DAMAGE]       = rootNode:getChildByTag(10023):getChildByTag(10017)
    self.mFunctionalSceneNode[global.MMO.NODE_UI_TOPMOST]   = rootNode:getChildByTag(10005):getChildByTag(10012)
    ...
    -- init hud root
    global.HUDManager:Init()
end

注意最后那句 global.HUDManager:Init()——座位表建完的第一个客户就是 HUD 管理器，它进场景头一件事是来领自己那排座位（头顶血条的挂点）。座位表不是建给人看的，是建给第一批租户用的，谁先来谁先挑，挑完各回各层。这个时序也解释了为什么 LoadGraph 必须是进图流程的最前置步骤：所有要往场景放东西的系统，都得等座位表发完号。

getChildByTag 链就是组织架构的路径：根 → 游戏世界(10023) → 角色层(10004) → 影子层(10007)。每个功能节点的"职务"靠它在树里的位置决定——渲染顺序就是树的先序遍历，先挂的画在底下。角色影子层排在角色本体层前面，所以影子永远垫在脚下；飘字层(DAMAGE)排在角色后面，所以伤害数字永远飘在人头上。这些"永远"不是巧合，是座位表写死的。

座位表建好后，全引擎任何系统想往场景里放东西，都走 GetSceneNode(nodeID) 查号入座：技能特效要垫在角色身后？GetSceneNode(NODE_SKILL_BEHIND)。伤害飘字要压在所有人头上？GetSceneNode(NODE_DAMAGE)。没人需要知道整棵树长什么样，人人只需要自己的座位号——这就是这张表存在的全部意义。

查号入座还有个销号的反向操作藏在 Cleanup 里：切图时按座位表逐层清子节点。也就是说这张表从建成那天起就身兼两职——渲染的顺序表加清理的遍历清单。一表两用是精明，也埋了一条纪律：凡是没上表的节点，清理时就是孤儿。这条纪律的后果我们在切图残影的排查里反复领教，后面第四节细说。

二、分层的颗粒度：影子里还有三层

这张座位表最震撼的细节是影子的细分：

self.mFunctionalSceneNode[global.MMO.NODE_ACTOR_SHADOW] =
    rootNode:getChildByTag(10023):getChildByTag(10004):getChildByTag(10007)
self.mFunctionalSceneNode[global.MMO.NODE_ACTOR_CLONE_SHADOW] =
    rootNode:getChildByTag(10023):getChildByTag(10004):getChildByTag(10030)
self.mFunctionalSceneNode[global.MMO.NODE_ACTOR_NPC_SHADOW] =
    rootNode:getChildByTag(10023):getChildByTag(10004):getChildByTag(10030):getChildByTag(10031)
self.mFunctionalSceneNode[global.MMO.NODE_ACTOR_MONSTER_SHADOW] =
    rootNode:getChildByTag(10023):getChildByTag(10004):getChildByTag(10030):getChildByTag(10032)
self.mFunctionalSceneNode[global.MMO.NODE_ACTOR_PLAYER_SHADOW] =
    rootNode:getChildByTag(10023):getChildByTag(10004):getChildByTag(10030):getChildByTag(10033)

影子不是一层，是三层：NPC 影子、怪物影子、玩家影子各占一个节点。为什么要拆？批量显隐。低配机的降级方案第一刀砍影子——一条 setVisible 关掉全部怪物影子；隐藏分类型的特殊需求（隐身术只藏玩家影子不藏怪影子）也有了挂点。同类型的对象共享一个父节点，是"批量操作"在场景树上的物理实现——这和 Buff 分色、通知分通道是同一个思想：分类是为了未来的批量操作。

分层的另一个收益是"层内互不干扰"。角色层（10004）里子节点再多，也压不过伤害飘字层（10017）——因为飘字在树上是它叔叔辈。角色站得再密、叠得再高，血条和飘字永远浮在最上，这就是"千人同屏血条不乱"的架构答案：不是每个血条在跟角色抢 zOrder，是它们根本不住一个楼层。

CLONE_SHADOW（克隆影子层）这个命名还有个故事可挖：变身卡、镜像分身这类"第二个自己"的影子单独一层，因为分身的影子显隐节奏和本体不同步——本体隐身了分身还在。引擎连"自己"和"假装自己"都分了座位，颗粒度较真到这个地步，才扛得住十几年的各种奇葩需求。

把整张座位表的层次从下到上念一遍，就是一部渲染的礼仪课本：地图切片垫底，技能身后的刀光贴地铺开，影子压在角色脚下，角色本体站中央，身前的特效飘落，伤害数字腾空，HUD 挂头顶，UI 压全场，最顶层留着弹窗和红点。每一层的存在都回答了"什么东西必须永远在什么东西的哪一边"——这张表就是二十年渲染需求的结晶，加一层要审慎，动一层要敬畏。

节点表里还能看到技能层拆成 SKILL_BEHIND 和 NODE_SKILL 两层：垫在角色身后的刀光、飘在角色身前的弹道各归各位。一刀劈下去，刀光在身后展开、剑气从身前掠过，这种电影感全靠两个节点的先后关系。你做新特效时先问"它在角色前面还是后面"，答案决定座位号，选错了怎么调 zOrder 都是错。

flowchart TD
A[LoadGraph 读导出场景] --> B[根节点挂入 cc.Scene]
B --> C[GAME_WORLD 10023]
C --> D[MAP 10003 → MAP_SLICE 10006]
C --> E[ACTOR 10004]
E --> F[SHADOW 10007 / CLONE_SHADOW 10030]
F --> G[NPC 10031 / MONSTER 10032 / PLAYER 10033]
E --> H[SPRITE 10008 / SFX_BEHIND 10016 / SFX_FRONT 10010]
C --> I[SKILL_BEHIND 10034 / SKILL 10015]
C --> J[DAMAGE 10017 / HUD 10009]
B --> K[UI 10005 → NORMAL 10011 / TOPMOST 10012]
K --> L[全部登记进 mFunctionalSceneNode]
L --> M[业务 GetSceneNode(号) 查表入座]

三、座位的代价：tag 链的脆弱与守护

座位表有个软肋明晃晃地摆着：tag 链是硬编码的路径，美术在编辑器里手滑删了一个节点，LoadGraph 的链式调用立刻拿到 nil，下游全部功能节点变空气。引擎的防御是两个：nil == scene.root 的总闸加 GetSceneNode 的 nodeID < NODE_NUM 越界检查——但链中间断掉的 tag 只有靠运行时报错兜底。某服美术改地图时删了个空节点，进游戏全场景无影子无 HUD，排查一下午发现是 tag 10030 的链断了。

治理方案是个笨办法但有效：场景导出文件的 tag 结构进版本管理，美术改场景必须跑一个 tag 校验脚本（校验全部功能 tag 存在），脚本过不了不允许提交。半天工时的脚本，之后五年没再断过链。约定容易破，工具守约难——能用脚本守住的事，别指望人记性。

tag 管理还有一个容易被忽略的分支问题：GetSceneNode 的越界判断只拦"超出 NODE_NUM 的号"，拦不住"号在范围内但 LoadGraph 没登记"的情况——后者返回的是 nil。所以业务代码从 GetSceneNode 拿到节点后的第一行永远是判空，判空不是不信任引擎，是不信任美术的手。防御性编程的分寸就在这里：对确定的东西检查边界，对不确定的东西检查存在。

四、实战案例：给特效加"穿墙层"

某服要做一个"全屏大招"，特效要盖住 UI 之外的一切（包括头顶血条）。需求下来第一反应是调 zOrder，调到 9999 发现盖不住 HUD 层——HUD 在另一个分支（10009），和特效层（10015）是平级节点，zOrder 只在同父内有效。

正确做法是在座位表上加一层：LoadGraph 里注册 NODE_SKILL_TOPMOST，挂在 UI 分支之前、游戏世界分支之后的位置，大招特效入座这一层。改动量：座位表加一行、特效入口改一个座位号，一小时上线。这个案例的要点是：跨分支的层级需求，答案永远在座位表上加座位，而不是在渲染顺序上打架。zOrder 管同层内排序，座位表管跨层归属，两层职责别搞混。

那一小时的工时单里还有半行容易被漏掉：新层的 Cleanup。切图时 NODE_SKILL_TOPMOST 里的残留大招特效要跟着场景走——座位表同时是清理清单，加座位就要把新座位加进切图清理的遍历范围。功能上线第一天没出事，第十天有玩家反馈"大招特效卡在屏幕上不掉"，就是清理清单漏了新座位。加一个座位 = 渲染位 + 清理位，两笔账一起记才是完整工时。

那次排查还总结出"层残影"三步口诀之外的另一条铁律：任何"加层"需求的工单，验收清单必须包含两项——新层的渲染正确性（对照座位表看顺序）和新层的清理正确性（切一百次图看残留）。渲染对了清理漏了，十天后的线上事故还是你的。一个座位两笔账，缺一笔都是完整工时的一半。

下面这个演示把座位表做成了可操作的：八个层开关对应八类功能节点，逐个关掉看画面怎么残——关影子怪变飘、关技能身后层刀光盖脸、关 HUD 血条消失、关地图全黑；点场景触发技能，看刀光在身后层展开、飘字在伤害层弹出，层的先后一目了然：

fx-scene-layers-1003f

四点五、切图清理：座位表同时是清理清单

讲切图。座位表的第二重身份很少有人强调：它同时是切图清理的遍历清单。切图时引擎沿座位表逐层清子节点，挂对位置的节点天然被清掉；绕过座位表挂到根上的节点，谁也不清——切图残留的"关不掉的 UI"就是这么来的。

由此推出排查口诀：看到切图残影，三步走——先查它挂在哪（是不是绕过了座位表），再查它的父层是否在清理遍历范围内，最后查它自己的 schedule 是否拉着自己不放。三步走完没有查不到的残影。口诀的底层还是那句话：查残影就是查"谁没上清单"。

给后来人的架构建议也顺势一条：扩展座位表时，新层的 tag 沿用引擎号段往下排，并且新层的创建必须和 LoadGraph 同文件——散落在业务代码里的 addChild 是座位表失守的第一步，守住"建层只在 LoadGraph"这条线，这张表就能一直干净下去。

五、常见疑问

问：为什么用 tag 而不用名字（getChildByName）？
tag 是整数比较，名字是字符串比较，LoadGraph 只在进图时执行一次，性能不是主因；真正的理由是 tag 跟随美术编辑器的导出规范，编辑器里节点属性直接填数字，导出即约定。名字给人看，tag 给程序看，两边各用各的寻址。

问：新功能层要插在两层中间怎么办？
重新导出场景文件加节点，LoadGraph 登记新号。插层会改变后续所有层的渲染顺序，所以加层是全局事件，必须回归测试全场景——这也是为什么引擎的功能层数量克制在二十个以内：层越多，加层的回归成本越高。

问：业务代码能不能绕过座位表直接往场景根挂东西？
能跑，但那是技术债。绕过座位表的节点不参与分层管理（批量显隐、层内排序都管不到它），还可能在切图时漏清——座位表同时是渲染结构和清理清单，游离于座位表之外的节点，游离于管理之外，切图残留的诡异 UI 十有八九是这么来的。

问：影子层为什么放在 SKILL_BEHIND 后面？
技能身后的刀光会盖住影子——光效比影子亮是物理直觉，影子垫在刀光下才自然。座位表的顺序细节背后全是这类物理常识的沉淀：改任何相邻两层顺序前，先问一句"自然界里谁盖住谁"，答案通常就出来了。

👉 完整课程入口：996 全套课程体系（千余节课录） ｜ 想跟浮生梦老师系统学的，看 LUA 高并发商业架构路径。