下载 App
西米：
问题1：食物图片单一
InjectFoods 和 GenerateDefaultFoods 都会设置 isDish=true+ingredientKeys，触发 Enemy.Spawn 中调用 ComposeDishSprite。但当食材有对应 JSON 文件时，ComposeDishSprite 成功生成 instancePixels 后，RenderEnemy 里有个 bug：
local cacheKey = instancePixels and nil or (e.npcFallbackType or e.typeName)
instancePixels 存在时 cacheKey = nil，导致下面 DrawPixelSpriteBatched 每帧重新调用 buildColorGroups，该函数计算量大，频繁触发会导致卡顿。
更关键的是：食材 JSON 只有 23 个，很多食材（如 radish、chicken 等）根本没有 image 字段，ComposeDishSprite 返回 nil，instancePixels 不被设置，最终所有这些食物都回退到 npcSpriteCache[typeName]——同一个 NPC 精灵。
现在了解了结构：ctx_.colorGroupCache 在 Render.InvalidateNpcCache() 和 Render.LoadNpcSprites() 中被清空，但 instanceColorGroupCache_ 是 RenderEnemy.lua 的模块级变量，没有随 ctx_.colorGroupCache 清空。
实际上分析一下：当前实现里，cacheKey = "inst_" .. e.id 时，缓存是写入 ctx_.colorGroupCache["inst_1"] 等。当 ctx_.colorGroupCache = {} 时（LoadNpcSprites 时），这些 inst 缓存也会被清空。这其实是正确的行为。
真正的问题：instanceColorGroupCache_ 这个额外的模块变量其实是多余且不一致的——真正的缓存在 ctx_.colorGroupCache，而 instanceColorGroupCache_ 只是无用的 nil 占位，不影响功能。核心修复（cacheKey = "inst_" .. e.id）已经正确了。
现在需要处理的是酶剥像素后缓存失效的问题：当 StripPixel 移除了某个像素后，该 enemy 的 ctx_.colorGroupCache["inst_" .. e.id] 应该失效，否则会显示旧的（未剥离的）像素。
检查 EnzymeParticle.StripPixel 调用后是否有让 Render 失效的机制：
关键发现：EnzymeParticle.StripPixel 在剥离像素后没有使 ctx_.colorGroupCache["inst_" .. target.id] 失效。这意味着酶剥后视觉上仍显示旧的完整像素（缓存未更新）。
需要三处改动：
EnzymeParticle.lua：StripPixel 后调用 renderModule_.InvalidateEnemyColorCache(target.id)
Render.lua：暴露 Render.InvalidateEnemyColorCache(enemyId) 代理到 RenderEnemy
Render.lua：在 LoadNpcSprites 清空 ctx_.colorGroupCache 时也清空 instanceColorGroupCache_（即调用 RenderEnemy.ClearInstanceCache()）
：
根本原因：两套数据系统不同步
Leaderboard 使用 foodAlerts_（只增不减的累计计数器）→ 显示"5份食物待处理"
BrainDashboard 使用 FoodPipeline.GetOrganQueue（云端实际队列）→ 食物被 ConsumeAndInjectFoods 消费后队列为空
当玩家进入口腔关卡，main.lua:515 调用 ConsumeFromOrgan("oral", 10, ...) 消费了云端队列，但 Leaderboard 的计数器不递减。
修复方案：
给 Leaderboard 添加递减接口和查询接口
在 FoodPipeline.ConsumeFromOrgan 成功时递减 Leaderboard 计数
BrainDashboard 融合两个数据源：云端队列优先（有详情），Leaderboard 计数兜底
：
一、先纠正一个关键误解
你说的"单机模式有 clientCloud，多人模式无 clientCloud"并不准确。实际情况是：
模式 clientCloud CloudProxy 路由
单机 ✅ 直接可用 CloudProxy:Set() → clientCloud:Set()
多人 ✅ 依然存在 CloudProxy:Set() → Client.CloudSave() → Server → serverCloud
CloudProxy 已经做了这个透明切换（CloudProxy.lua:46-57）。所以不存在"有/无 clientCloud"的问题——两种模式下 CloudProxy 的接口完全一致，只是底层路由不同。
这意味着 MapEditor 用 cloud:Set("map_xxx", data) 保存的地图，在两种模式下都能工作——但存到了不同的地方：
单机：存进你自己的 clientCloud 个人空间
多人：存进 serverCloud 的你的 userId 分区
两种模式下，其他玩家都读不到你的地图。 这才是核心问题。