# FishDice 缺点与风险

← 返回总览 缺点与风险

# 当前框架的缺点、风险和补强方向

FishDice 的核心设计很干净，但它的能力边界也很明显：目前完成的是玩法决策闭环，不是资源、UI、场景、服务和目标玩法全链路框架。

## 主要缺点

问题 | 风险 | 建议
--- | --- | ---
配置仍内建在代码中 | 策划无法独立调规则、权重、候选、模式映射；发版成本高。 | 把 definition 层迁移到 JSON/ScriptableObject/远端表，但保留现有 validator。
没有生产级资源映射 | result key 到图标、动画、prefab、音效的关系尚未定义。 | 增加 Unity Integration 层，保持 Runtime 只认 key。
UI 只是 Demo | 没有 panel 生命周期、导航、层级、动画完成回调、数据绑定约定。 | 建立 LuckyDicePresentation 或 Presenter/ViewModel，再接项目 UI 框架。
TargetMode 只解析，不启动 | 核心能产出 `slap_down_normal`，但没有真实玩法启动器。 | 补 `TargetModeLauncher` 接口和 Unity 层实现。
Lucky Dice 筛选策略写死在 service 中 | 后续 cooldown、tutorial、活动来源、权重策略复杂后，service 会膨胀。 | 把 filter 抽成可注册 pipeline，并让 Trace 记录每个 filter 的前后数量。
Trace 目前是内存结果，不是日志系统 | 线上复盘还缺持久化、埋点、采样和导出协议。 | 新增 Trace sink 或 adapter，把核心 trace 转接到日志/埋点系统。
异常和失败策略还偏工程化 | 部分错误通过 exception 抛出，生产玩法可能需要降级而不是中断。 | 区分配置启动期错误、请求错误、运行期可恢复错误。

## 最需要优先补的三件事

### 1. 配置外置

先让规则、候选、target mode 从外部数据创建，并保留现有校验链。

### 2. 目标玩法启动协议

定义 `TargetModeEntry` 到真实玩法模块的启动、完成、失败回调。

### 3. 表现层资源映射

补齐 `ResultKey` 对应 icon/slot/prefab/动画资源的统一表。

## 需要避免的后续走偏

不要为了快速接 UI，把 Sprite、Prefab、Canvas、Coroutine 或场景跳转塞回 Runtime。那会破坏当前最有价值的纯核心边界。
不要把新组合直接写成 `if normalizedKey == ...` 的业务方法。组合增长应优先走规则配置和 matcher/action 扩展。

## 证据

- LuckyDiceDefaultConfig.cs:151-238：默认配置仍在代码内。
- LuckyDiceFlowService.cs:21-25：候选筛选条件直接写在 service 内。
- TargetModeResolver.cs:9-33：只解析 target mode，不负责启动真实玩法。
- LuckyDiceDemoController.cs:131-244：UI 是 Demo 代码构建，不是可复用 UI 管理器。
- rg Addressables/AssetBundle/LoadAsset：当前没有资源加载/映射框架证据。