打通投喂→游戏玩法信道

以下是关于 “打通投喂→游戏玩法信道” 的架构讨论。

当前状态已有的：

数据流设计方案核心链路：投喂(Leaderboard)

  → 写入"待消化食物队列"(持久化)

    → 口腔关卡读取队列，生成食物NPC(Enemy.Spawn)

      → 食物经过口腔处理(碎裂/酶解)

        → 器官传递(胃→小肠→大肠)

          → 每个环节影响暗线指标(血糖/血脂/血钠)

            → 大脑监控室实时反映变化

            → 大脑食物图鉴记录

关键设计节点1. 待消化食物队列（核心中间件）这是整条链路的枢纽。投喂产生食物，口腔消费食物，需要一个队列连接两端：pendingFoods = {

    { foodKey = "spinach", feederId = 1051336128, timestamp = os.time() },

    { foodKey = "apple",   feederId = 0,          timestamp = os.time() },  -- 0 = 自己投喂自己

}

存储位置有两个选择：方案存储优点缺点A. 内存队列GameState 本地变量简单、即时刷新页面丢失，只适合单机B. clientCloud云变量跨会话持久、支持多人互喂有延迟、需要轮询考虑到你当前是单机模式（.project/settings.json 的 multiplayer.enabled 是 false），方案 A（内存队列）做 MVP 最快，后续切多人时再升级为方案 B。2. 投喂动作触发（Leaderboard → GameState）点击食物卡片时：

总结：需要新增/修改的模块模块改动工作量GameState.lua新增 pendingFoodQueue、PushFood()、PopFood()、GetPendingFoods()小Leaderboard.lua食物点击回调中调用 GameState.PushFood() + GameState.RecordFoodIntake()小Config.lua为5个食物类别定义 EnemyType 模板 + 指标影响规则中Enemy.luaSpawn() 支持从 pendingFoodQueue 取食物，叠加食物名称/图标中BeatSystem.lua节拍开始时检查 pendingFoodQueue，生成对应食物波次小BrainDashboard.lua无需改动（已有读取通道）无总体来说，核心改动集中在 GameState（队列）和 Enemy（映射+生成）两个模块，其他模块只需少量对接代码。