提交文档

docs/guides/loxodon-framework-core-analysis.md

@@ -0,0 +1,350 @@
+# Loxodon Framework Core 分析
+
+> 分析对象：<https://github.com/vovgou/loxodon-framework/tree/master/Loxodon.Framework/Assets/LoxodonFramework>
+>
+> 分析日期：2026-06-12
+
+## 结论
+
+Loxodon Framework 的 Core 本质上是一个 **Unity MVVM + DataBinding 运行时核心**，而不是覆盖完整游戏生命周期的游戏框架内核。
+
+它的核心价值集中在：
+
+- 用 `Context` 和 `ServiceContainer` 提供全局/局部上下文与轻量服务注册。
+- 用 `BindingServiceBundle` 装配 DataBinding 所需的 Parser、Converter、SourceProxy、TargetProxy、Binder。
+- 用 `ViewModelBase`、`ObservableObject`、Observable Collection 支撑 ViewModel 状态变化。
+- 用 `UIView`、`Window`、`WindowManager` 提供 UI 视图、窗口状态和转场管理。
+- 用 `Messenger`、`Command`、`Async`、`Prefs`、`Localization` 等模块补齐 MVVM UI 开发所需的基础设施。
+
+因此，Loxodon 更适合作为 FlowScope 的 **UI / Binding / ServiceBundle 外围模块参考**，不适合作为 FlowScope Kernel 的边界模板。
+
+## Core 模块拆解
+
+### Context
+
+源码位置：
+
+- <https://github.com/vovgou/loxodon-framework/blob/master/Loxodon.Framework/Assets/LoxodonFramework/Runtime/Framework/Contexts/Context.cs>
+- <https://github.com/vovgou/loxodon-framework/blob/master/Loxodon.Framework/Assets/LoxodonFramework/Runtime/Framework/Contexts/ApplicationContext.cs>
+
+`Context` 维护静态 `ApplicationContext` 和按 key 注册的多个 `Context`，每个 Context 内部有：
+
+- `IServiceContainer`
+- 属性字典
+- 可级联查询的 parent context
+
+`ApplicationContext` 在 `Context` 基础上补了：
+
+- `IMainLoopExecutor`
+- Global Preferences
+- User Preferences
+
+这个设计方便应用层快速拿到全局能力，但也说明 Loxodon 的 Core 并不是纯机制内核。它把主线程执行器和 Prefs 这类应用级能力直接放进了全局上下文。
+
+### ServiceContainer
+
+源码位置：
+
+- <https://github.com/vovgou/loxodon-framework/blob/master/Loxodon.Framework/Assets/LoxodonFramework/Runtime/Framework/Services/ServiceContainer.cs>
+- <https://github.com/vovgou/loxodon-framework/blob/master/Loxodon.Framework/Assets/LoxodonFramework/Runtime/Framework/Services/AbstractServiceBundle.cs>
+- <https://github.com/vovgou/loxodon-framework/blob/master/Loxodon.Framework/Assets/LoxodonFramework/Runtime/Framework/Services/IServiceBundle.cs>
+
+`ServiceContainer` 是轻量服务定位器，支持：
+
+- 按 `Type` 注册对象或 factory。
+- 按 `string name` 注册对象或 factory。
+- `Resolve<T>()` / `Resolve(string)` 解析服务。
+- `Unregister<T>()` / `Unregister(string)` 注销服务。
+
+`ServiceBundle` 是模块装配入口：
+
+```csharp
+public interface IServiceBundle
+{
+    void Start();
+    void Stop();
+}
+```
+
+`AbstractServiceBundle` 把容器传给 `OnStart` / `OnStop`，由具体 bundle 负责注册和注销一组服务。
+
+这个模式对 FlowScope 有参考价值：模块可以用显式 `Start/Stop` 完成能力注册，避免散落的静态初始化。
+
+### Binding
+
+源码位置：
+
+- <https://github.com/vovgou/loxodon-framework/blob/master/Loxodon.Framework/Assets/LoxodonFramework/Runtime/Framework/Binding/BindingServiceBundle.cs>
+- <https://github.com/vovgou/loxodon-framework/tree/master/Loxodon.Framework/Assets/LoxodonFramework/Runtime/Framework/Binding>
+
+Binding 是 Loxodon Core 最厚、最核心的部分。
+
+`BindingServiceBundle` 会装配：
+
+- `PathParser`
+- `ExpressionPathFinder`
+- `ConverterRegistry`
+- `ObjectSourceProxyFactory`
+- `SourceProxyFactory`
+- `TargetProxyFactory`
+- `BindingFactory`
+- `StandardBinder`
+
+然后注册：
+
+- `IBinder`
+- `IBindingFactory`
+- `IConverterRegistry`
+- `IExpressionPathFinder`
+- `IPathParser`
+- `INodeProxyFactory`
+- `ISourceProxyFactory`
+- `ITargetProxyFactory`
+
+这说明 Loxodon 的 Binding 不是简单的反射赋值，而是一条可扩展管线：
+
+```text
+BindingDescription
+  -> Path / Expression
+  -> SourceProxy
+  -> Converter
+  -> TargetProxy
+  -> Binding
+```
+
+README 也强调该框架围绕 DataBinding 做了性能优化：减少装箱、降低 GC、通过动态委托或静态织入降低反射成本。
+
+### ViewModel / Observable
+
+源码位置：
+
+- <https://github.com/vovgou/loxodon-framework/blob/master/Loxodon.Framework/Assets/LoxodonFramework/Runtime/Framework/ViewModels/ViewModelBase.cs>
+- <https://github.com/vovgou/loxodon-framework/blob/master/Loxodon.Framework/Assets/LoxodonFramework/Runtime/Framework/Observables/ObservableObject.cs>
+- <https://github.com/vovgou/loxodon-framework/tree/master/Loxodon.Framework/Assets/LoxodonFramework/Runtime/Framework/Observables>
+
+`ViewModelBase` 继承 `ObservableObject`，核心职责是：
+
+- 封装属性变更。
+- 触发 `PropertyChanged`。
+- 可选通过 `IMessenger` 广播 `PropertyChangedMessage<T>`。
+
+典型路径是：
+
+```text
+ViewModel property set
+  -> Set<T>
+  -> field updated
+  -> RaisePropertyChanged
+  -> optional Messenger.Publish(PropertyChangedMessage<T>)
+  -> Binding updates target UI
+```
+
+这是标准 MVVM 的数据驱动 UI 模型。
+
+### View / Window
+
+源码位置：
+
+- <https://github.com/vovgou/loxodon-framework/blob/master/Loxodon.Framework/Assets/LoxodonFramework/Runtime/Framework/Views/UIView.cs>
+- <https://github.com/vovgou/loxodon-framework/blob/master/Loxodon.Framework/Assets/LoxodonFramework/Runtime/Framework/Views/Window.cs>
+- <https://github.com/vovgou/loxodon-framework/blob/master/Loxodon.Framework/Assets/LoxodonFramework/Runtime/Framework/Views/WindowManager.cs>
+
+`UIView` 负责 Unity UI 基础行为：
+
+- `RectTransform`
+- `CanvasGroup`
+- `Visibility`
+- Enter / Exit Animation
+- Enable / Disable event
+
+`Window` 在 `UIView` 基础上增加：
+
+- `WindowType`
+- `windowPriority`
+- `WindowState`
+- activated / dismissed / visibility changed event
+- state broadcast
+
+`WindowManager` 管理窗口集合、当前窗口、可见窗口和转场执行。
+
+这部分是 UI 框架能力，不是游戏 Feature 生命周期管理。
+
+### Messaging / Command / Async / Prefs
+
+源码位置：
+
+- <https://github.com/vovgou/loxodon-framework/blob/master/Loxodon.Framework/Assets/LoxodonFramework/Runtime/Framework/Messaging/Messenger.cs>
+- <https://github.com/vovgou/loxodon-framework/blob/master/Loxodon.Framework/Assets/LoxodonFramework/Runtime/Framework/Commands/RelayCommand.cs>
+- <https://github.com/vovgou/loxodon-framework/tree/master/Loxodon.Framework/Assets/LoxodonFramework/Runtime/Framework/Asynchronous>
+- <https://github.com/vovgou/loxodon-framework/blob/master/Loxodon.Framework/Assets/LoxodonFramework/Runtime/Framework/Prefs/Preferences.cs>
+
+这些模块服务于 MVVM/UI 工程化：
+
+- `Messenger`：按消息类型和 channel 做发布订阅。
+- `RelayCommand`：给 UI 事件绑定命令。
+- `AsyncResult` / `ProgressResult` / `CoroutineTask`：把异步、协程、进度结果统一成可等待对象。
+- `Preferences`：默认基于 `PlayerPrefs`，支持全局和用户偏好。
+
+这些能力有实用价值，但它们放在 Core 中会让 Core 变厚。对 FlowScope 来说，应当拆成独立模块或适配层，而不是进入 Kernel。
+
+## 架构优点
+
+### 1. MVVM UI 工程化成熟
+
+Binding、ViewModel、Command、Window、Messenger 形成了完整闭环。对于 UI 重、状态同步复杂、需要数据绑定的 Unity 项目，Loxodon 能显著减少手写 UI 刷新代码。
+
+### 2. Binding 管线拆得足够细
+
+`SourceProxy`、`TargetProxy`、`Converter`、`PathParser`、`Binder` 的拆分使绑定系统具备较强扩展性。不同 UI 系统或不同数据源可以通过 proxy/factory 接入，而不是改主流程。
+
+### 3. ServiceBundle 模式简单可控
+
+`Start/Stop` 注册/注销一组服务，适合插件化装配。相比全局静态初始化，这种方式更容易表达模块边界。
+
+### 4. 有性能意识
+
+README 中明确强调减少 value type 装箱、减少 GC、优化绑定性能。这说明 Loxodon 的设计目标不是单纯追求抽象，而是面向 Unity UI 高频更新场景。
+
+## 架构局限
+
+### 1. Core 边界偏厚
+
+`ApplicationContext` 直接提供主线程执行器和 Preferences，`Preferences` 默认落到 `PlayerPrefs`，`Messenger.Default` 也带有全局静态倾向。
+
+这些设计让使用更方便，但会让 Core 逐步吸收平台、存储、消息、UI 等应用级能力。
+
+### 2. 不是完整游戏框架内核
+
+Loxodon Core 没有把以下能力作为主轴：
+
+- 游戏 Feature 生命周期
+- 模块启动顺序
+- 资源后端边界
+- 配置表加载边界
+- 存档版本迁移
+- 热更新策略
+- 场景/流程切换策略
+
+它的插件生态里有 Addressable、Data、XLua、ILRuntime 等扩展，但 Core 本体的主轴仍然是 MVVM/DataBinding。
+
+### 3. 对小团队很省事，对强边界内核有侵蚀风险
+
+如果项目目标是快速做 UI 驱动业务，Loxodon 的全局上下文和内置 Prefs 会很方便。
+
+但如果目标是 FlowScope 这种机制型内核，直接照搬会让 Kernel 同时承担 UI、Prefs、Messaging、Async、Binding 等职责，边界会变得越来越难控。
+
+## 对 FlowScope 的借鉴建议
+
+### 可以借鉴
+
+1. **ServiceBundle 的模块装配方式**
+
+   FlowScope 的 P1/P2 模块可以采用类似显式装配模式：
+
+   ```text
+   ModuleBundle.Start(container)
+     -> register contracts
+     -> register default implementations
+     -> register adapters
+
+   ModuleBundle.Stop(container)
+     -> unregister contracts
+     -> release module-owned state
+   ```
+
+2. **Binding 管线的分层思想**
+
+   如果 FlowScope 后续需要 UI Binding 或 Editor Binding，可以参考 Loxodon 的拆分：
+
+   ```text
+   Source
+   Target
+   Path
+   Converter
+   Binder
+   BindingContext
+   ```
+
+   但这应该作为 UI 扩展模块，而不是 Kernel 机制。
+
+3. **ViewModelBase 的属性变更封装**
+
+   `Set<T>` 模式可以降低 ViewModel 代码重复，也能统一 PropertyChanged 和消息广播策略。
+
+4. **Window 状态模型**
+
+   `Window` / `WindowManager` 对弹窗、页面、转场、可见性和激活状态有参考价值，可用于 FlowScope UI 模块设计。
+
+### 不建议照搬
+
+1. **不要把 Prefs 放进 Kernel**
+
+   FlowScope 的 Save / Prefs / PlayerPrefs 应保持在 Save 模块或 Unity Adapter 中。
+
+2. **不要把 Messenger 作为 Kernel 默认通信机制**
+
+   消息总线容易变成隐式耦合通道。Kernel 应保持 Feature 生命周期和 Slot/Policy 机制清晰，事件系统应作为 P1/P2 模块单独设计。
+
+3. **不要把 UI Window 放进 Kernel**
+
+   UI 是 Feature/Module 的外围能力。Kernel 只需要管理 Feature 的启动、替换、停止策略，不应知道 Window 栈。
+
+4. **不要用全局 ApplicationContext 承载所有能力**
+
+   FlowScope 更适合显式 Bootstrap + Container + FeatureContext。全局上下文可以作为上层便利入口，但不应成为 Kernel 的事实中心。
+
+## 与 FlowScope Kernel 边界的关系
+
+FlowScope 当前更适合保持：
+
+```text
+Kernel
+  -> Container
+  -> AppKernel
+  -> StartupPipeline
+  -> FeatureHost
+  -> FeatureInstance
+  -> FeatureContext
+  -> FeatureLifetime
+  -> FeatureSlot
+  -> FeaturePolicy
+```
+
+Loxodon 的能力更适合放在：
+
+```text
+FlowScope.UI
+  -> ViewModel
+  -> Binding
+  -> Window / Panel
+  -> Command
+
+FlowScope.Events
+  -> Messenger / EventBus
+
+FlowScope.Save.Unity
+  -> PlayerPrefs adapter
+
+FlowScope.Runtime.Extensions
+  -> ServiceBundle helpers
+```
+
+换句话说，Loxodon 对 FlowScope 的启发是：**外围模块可以做厚，Kernel 必须保持薄。**
+
+## 最终判断
+
+Loxodon Framework 的 Core 是一个成熟的 Unity MVVM/UI 运行时。它适合解决 UI 数据绑定、ViewModel 状态传播、窗口管理和 UI 事件命令化问题。
+
+但它不是 FlowScope Kernel 的直接模板。对 FlowScope 来说，最值得吸收的是：
+
+- `ServiceBundle` 式模块装配。
+- Binding 管线拆分方式。
+- ViewModel 属性变更封装。
+- Window 状态管理经验。
+
+最需要避免的是：
+
+- 把 Prefs、UI、Messaging、Binding 一起塞进 Core。
+- 用全局上下文替代显式生命周期。
+- 让 Kernel 从机制层滑向应用便利层。
+

docs/guides/qframework-core-analysis.md

@@ -0,0 +1,501 @@
+# QFramework Core 细读与 FlowScope 借鉴边界
+
+更新时间：2026-06-12
+
+参考源码：<https://github.com/liangxiegame/QFramework/blob/master/QFramework.cs>
+
+本文分析 QFramework 单文件 Core 的架构设计、适用范围、优缺点，以及它对 FlowScope Kernel / CoreModules 的可借鉴部分。本文不是选型结论，也不是实现计划；它用于后续讨论 FlowScope 业务架构层、事件层、状态层时作为参考。
+
+## 1. 总结
+
+QFramework Core 的价值不在于提供完整商业游戏运行时，而在于用很少的类型固定 Unity 业务代码的依赖方向。
+
+它的核心模型可以概括为：
+
+```text
+Architecture<T>
+  -> IOCContainer
+  -> Model / System / Utility
+  -> Command / Query
+  -> Event / BindableProperty
+
+Controller / MonoBehaviour
+  -> SendCommand / SendQuery
+  -> GetModel / GetSystem
+  -> RegisterEvent
+```
+
+QFramework Core 解决的是 Unity 项目里常见的“表现层乱改状态、MonoBehaviour 互相引用、业务逻辑没有入口、通知链路散落”的问题。它不是资源框架、UI 框架、热更框架、构建框架，也不负责 Feature、场景、流程或模块生命周期编排。
+
+对 FlowScope 来说，QFramework Core 最值得借鉴的是：
+
+- 状态变更必须有入口。
+- 上层可以调用下层，下层不直接引用上层。
+- 下层通过事件或可观察状态通知上层。
+- Command / Query 是短生命周期行为对象，不承载长期状态。
+- 用能力接口限制对象可访问的架构能力。
+
+不适合直接照搬的是：
+
+- 静态全局 `Architecture<T>.Interface` 入口。
+- 强制 `Model / System / Utility / Command` 成为 Kernel 业务分层。
+- 没有 RootScope / FeatureScope 的单容器模型。
+- 没有 Feature 级生命周期和释放边界。
+- 把 Event / BindableProperty 作为所有项目默认基础设施。
+
+## 2. Core 范围
+
+QFramework.cs 里的核心组成大致分为以下几组。
+
+| 组 | 类型 | 职责 |
+| --- | --- | --- |
+| 架构根 | `IArchitecture`, `Architecture<T>` | 注册和获取 Model / System / Utility，执行 Command / Query，发送和注册事件 |
+| 表现层协议 | `IController` | 通常由 MonoBehaviour 实现，负责接入架构，不直接持有业务状态 |
+| 业务逻辑层 | `ISystem`, `AbstractSystem` | 放跨表现层共享的业务逻辑 |
+| 数据层 | `IModel`, `AbstractModel` | 放状态和数据操作 |
+| 工具层 | `IUtility` | 放外部能力适配，例如存储、SDK、序列化 |
+| 行为对象 | `ICommand`, `ICommand<TResult>`, `IQuery<TResult>` | 封装写操作和读操作 |
+| 能力接口 | `ICanGetModel`, `ICanSendCommand` 等 | 用接口组合限制对象能做什么 |
+| 事件系统 | `TypeEventSystem`, `EasyEvent` | 按类型注册、发送、反注册事件 |
+| 可绑定状态 | `BindableProperty<T>` | 值变化时通知订阅者 |
+| 容器 | `IOCContainer` | 按类型注册和解析实例 |
+
+这个范围说明 QFramework Core 更接近“业务代码架构层”，而不是“应用 Kernel”。它把代码写法约束住，但不管理完整应用运行期。
+
+## 3. Architecture<T>
+
+`Architecture<T>` 是 QFramework 的架构根。它使用静态字段保存当前架构实例，`Interface` 首次访问时触发初始化。
+
+典型启动过程：
+
+1. 创建 `T : Architecture<T>` 实例。
+2. 调用子类实现的 `Init()`。
+3. 在 `Init()` 中注册 Model、System、Utility。
+4. 执行 `OnRegisterPatch`。
+5. 初始化所有未初始化的 Model。
+6. 初始化所有未初始化的 System。
+7. 将架构标记为已初始化。
+
+反初始化过程：
+
+1. 调用 `OnDeinit()`。
+2. 对已初始化的 System 调用 `Deinit()`。
+3. 对已初始化的 Model 调用 `Deinit()`。
+4. 清空容器。
+5. 清空静态架构实例。
+
+这个设计很适合中小项目：入口少、初始化简单、读源码很快。它的问题也同样明确：全局静态入口会自然演化成 Service Locator，业务对象很容易绕开组合根直接拿依赖。
+
+FlowScope 不应该照搬这个入口。FlowScope 的 Kernel 需要显式 `AppKernel`、`RootScope`、`StartupPipeline` 和 `FeatureHost`，让启动顺序、依赖边界和关闭顺序都可测试、可替换、可释放。
+
+## 4. Model / System / Utility
+
+QFramework 的分层规则可以简化理解为：
+
+```text
+Controller -> Command / Query -> System / Model -> Utility
+Model / System -> Event / BindableProperty -> Controller
+```
+
+### Model
+
+`IModel` 表示数据层。它可以：
+
+- 持有状态。
+- 调用 Utility。
+- 发送事件。
+- 初始化和反初始化。
+
+它不应该直接引用 Controller，也不应该直接操作 UI。
+
+### System
+
+`ISystem` 表示共享业务逻辑层。它可以：
+
+- 获取 Model。
+- 获取 Utility。
+- 获取其他 System。
+- 注册事件。
+- 发送事件。
+- 初始化和反初始化。
+
+System 适合放跨 UI、跨场景、跨表现层复用的业务逻辑。它比 Model 更偏行为，比 Controller 更偏领域。
+
+### Utility
+
+`IUtility` 是最薄的一层，只是一个标记接口。它通常承载外部能力，例如：
+
+- 本地存储。
+- 网络 SDK。
+- 平台 SDK。
+- JSON 序列化。
+- 时间服务。
+
+Utility 本身不被强制注入 Architecture，这也意味着它更像纯工具或外部适配器。
+
+### 对 FlowScope 的启发
+
+FlowScope Kernel 不应该规定 `Model / System / Utility`。这是项目业务架构选择，不是 Kernel 机制。
+
+但 FlowScope 可以在 CoreModules 或推荐模板里提供类似规则：
+
+- Feature 内部状态归 Feature 自己或 Feature-scoped state service。
+- 跨 Feature 长期状态归 Root-scoped service。
+- 外部能力通过接口注册到 RootScope。
+- UI 和 MonoBehaviour 不直接写长期状态，而是调用 UseCase、Command 或 Service 方法。
+
+## 5. Command / Query
+
+QFramework 用 Command 作为状态变更入口，用 Query 作为读操作入口。
+
+Command 的特征：
+
+- 短生命周期。
+- 执行前被注入 Architecture。
+- 可获取 Model / System / Utility。
+- 可发送事件。
+- 可继续发送其他 Command 或 Query。
+- 不保存长期状态。
+
+Query 的特征：
+
+- 短生命周期。
+- 执行前被注入 Architecture。
+- 主要读取 Model / System。
+- 返回查询结果。
+
+这个设计的好处是把“写操作”从 Controller 中拿出来。Controller 不再到处写：
+
+```csharp
+model.Coins.Value += 10;
+```
+
+而是写：
+
+```csharp
+this.SendCommand(new AddCoinCommand(10));
+```
+
+这样状态变化可以被搜索、测试和复用。
+
+对 FlowScope 来说，这个思想很值得吸收，但名称和形态不应进 Kernel。Kernel 不应该强制所有状态变更都叫 Command。项目可以选择：
+
+- `Command`
+- `UseCase`
+- `Action`
+- `Service Method`
+- `Application Service`
+
+Kernel 只需要保证依赖边界和生命周期，不需要规定业务行为对象的命名体系。
+
+## 6. 能力接口组合
+
+QFramework 一个很好的设计点是能力接口组合。
+
+例如：
+
+- `ICanGetModel`
+- `ICanGetSystem`
+- `ICanGetUtility`
+- `ICanSendCommand`
+- `ICanSendEvent`
+- `ICanRegisterEvent`
+- `ICanSendQuery`
+
+这些接口本身几乎没有实现，实际能力通过扩展方法提供。对象只有实现了对应接口，才获得对应扩展方法。
+
+这带来的好处是：
+
+- Controller 能做的事和 Model 能做的事不同。
+- Model 可以发事件，但不能随意发 Command。
+- Command 可以访问 Model/System/Utility，但不变成长期服务。
+- 架构规则体现在类型系统里，而不是只写在文档里。
+
+这个方向对 FlowScope 有参考价值。FlowScope 如果后续做业务架构层，可以避免提供一个万能 `FeatureContext`。更好的方式是拆小能力：
+
+```text
+ICanResolveService
+ICanPublishEvent
+ICanReadState
+ICanExecuteUseCase
+ICanRegisterLifetime
+```
+
+但这些应属于 P1/P2 业务层或扩展层。Kernel 的 `FeatureContext` 仍应保持最小，只暴露 Scope、Lifetime、CancellationToken、Handle 等机制概念。
+
+## 7. TypeEventSystem
+
+QFramework 的 `TypeEventSystem` 是一个按事件类型分发的轻量事件系统。
+
+它的核心机制：
+
+```text
+TypeEventSystem
+  -> EasyEvents
+    -> Dictionary<Type, IEasyEvent>
+      -> EasyEvent<T>
+```
+
+发送事件时按 `EasyEvent<T>` 类型取出事件对象并触发。注册事件时如果没有对应事件对象，就创建一个。
+
+优点：
+
+- 使用简单。
+- 类型安全。
+- 适合 UI 刷新和轻量业务通知。
+- 反注册模型清晰。
+
+风险：
+
+- 没有作用域隔离。
+- 没有事件优先级。
+- 没有异步派发协议。
+- 没有错误隔离。
+- 没有事件链路追踪。
+- 大型项目里容易变成全局黑箱。
+
+FlowScope 可以借鉴“下层发事件，上层订阅”的方向，但 EventBus 不应进入 Kernel 主依赖。更合理的位置是 `FlowScope.Events` 或 P1 Events 模块：
+
+```text
+Kernel
+  不知道 EventBus
+
+P1 Events
+  注册 IEventBus 到 RootScope
+  提供 FeatureLifetime 可登记的订阅句柄
+  提供同步或异步事件策略
+```
+
+这样 Feature 可以使用事件，但 Kernel 不被事件模型绑死。
+
+## 8. BindableProperty<T>
+
+`BindableProperty<T>` 是一个可观察值对象。它在 `Value` 变化时触发 `EasyEvent<T>`，并提供：
+
+- `Register`
+- `RegisterWithInitValue`
+- `UnRegister`
+- `SetValueWithoutEvent`
+- 自定义比较器
+
+它适合表达 UI 绑定和简单状态监听，例如金币、生命值、进度条、开关状态。
+
+优点：
+
+- 简单直接。
+- UI 订阅体验好。
+- `RegisterWithInitValue` 避免 UI 初始刷新遗漏。
+- 对中小项目足够实用。
+
+风险：
+
+- 比较器是静态泛型级别配置，使用时要小心全局影响。
+- 复杂状态容易被拆成大量可绑定字段，导致状态事务边界不清。
+- 不适合表达复杂异步流、错误流、完成流。
+- 如果到处暴露可写 `BindableProperty<T>`，仍然会出现状态乱改。
+
+FlowScope 可以把类似能力放到状态或 UI 扩展模块，但不应放进 Kernel。Kernel 只负责 Feature 生命周期；状态响应式属于业务层或表现层。
+
+## 9. IOCContainer
+
+QFramework 的 `IOCContainer` 很小：
+
+- `Register<T>(T instance)` 按 `typeof(T)` 注册。
+- `Get<T>()` 按 `typeof(T)` 获取。
+- `GetInstancesByType<T>()` 枚举所有兼容类型实例。
+- `Clear()` 清空。
+
+优点：
+
+- 极易理解。
+- 调试成本低。
+- 足够支撑 QFramework 的 Model/System/Utility 注册。
+
+不足：
+
+- 没有构造函数注入。
+- 没有 Scope。
+- 没有生命周期释放。
+- 没有 `IDisposable` / `IAsyncDisposable` 管理。
+- 没有多绑定。
+- 没有 named/keyed service。
+- 没有循环依赖检测。
+- 没有线程安全。
+
+FlowScope 可以借鉴“按类型注册和解析”的最小体验，但实现必须比 QFramework 的容器多一层生命周期能力：
+
+```text
+RootScope
+  长生命周期服务
+
+FeatureScope
+  Feature 实例和本次启动参数
+  先查本地，再回退 RootScope
+
+FeatureLifetime
+  释放运行期句柄、订阅、资源组、临时对象
+```
+
+这也是 FlowScope 不能直接采用 QFramework IOC 的核心原因。
+
+## 10. 生命周期对比
+
+| 维度 | QFramework Core | FlowScope Kernel 目标 |
+| --- | --- | --- |
+| 应用入口 | 静态 `Architecture<T>.Interface` | 显式 `AppKernel` |
+| 启动流程 | 首次访问时初始化 | `StartupPipeline` 顺序执行 |
+| 依赖容器 | 单个 `IOCContainer` | `RootScope + FeatureScope` |
+| 业务运行单元 | Model/System 长驻 | Feature 实例 |
+| Feature 生命周期 | 不负责 | `LoadAsync / EnterAsync / ExitAsync` |
+| 释放边界 | Model/System Deinit，容器 Clear | `FeatureLifetime + FeatureScope + RootScope` |
+| 异步关闭 | 不突出 | Kernel 必须处理 async stop/shutdown |
+| 运行位置 | 不负责 | `FeatureSlot + FeaturePolicy` |
+
+QFramework 的生命周期适合“一个游戏一个 Architecture，若干长驻 Model/System”。FlowScope 的目标是“一个应用 Kernel 管多个 Feature 实例，每个 Feature 有独立依赖边界和释放边界”。
+
+这两个方向不冲突，但层级不同。QFramework 更像可选的业务组织方式，FlowScope Kernel 更像运行机制。
+
+## 11. 与完整框架的横向比较
+
+| 维度 | QFramework Core | UnityGameFramework | ET Framework | TinaX | FlowScope 应吸收 |
+| --- | --- | --- | --- | --- | --- |
+| 核心定位 | 轻量业务分层 | 客户端模块全家桶 | 双端大型联网运行时 | 服务化 Package 框架 | 小 Kernel + 可选模块 |
+| 启动入口 | Architecture | GameEntry / Procedure | Scene / Fiber / Actor | Core service bootstrap | AppKernel / StartupPipeline |
+| 资源系统 | Core 不负责 | 内置 Resource | 可接入包和热更链路 | VFS | P1 Resources 模块 |
+| UI | Core 不负责，UIKit 在工具生态 | 内置 UI 模块 | 通常通过包扩展 | UIKit | P1 UI 模块 |
+| 事件 | TypeEventSystem | Event 模块 | 消息/事件体系 | Event/System service | P1 Events 模块 |
+| 状态变更 | Command | 模块 API / Procedure | Entity/System/消息 | Service API | 可选 Command/UseCase |
+| 工程流水线 | 不负责 | 部分覆盖 | 强工具链 | Package 化 | Tools/Package 后续模块 |
+
+QFramework 在这张表里的优势是轻量和清晰。它不应该被拿来和 UGF 的资源/UI/Procedure 覆盖度硬比，也不应该被要求承担 BDFramework 的热更构建流水线职责。
+
+## 12. 对 FlowScope 的建议
+
+### 12.1 Kernel 不吸收 QFramework 分层
+
+FlowScope Kernel 继续保持：
+
+```text
+AppKernel
+StartupPipeline
+FeatureHost
+Container
+FeatureLifetime
+FeatureSlot
+FeaturePolicy
+IFeature
+FeatureContext
+FeatureHandle
+```
+
+Kernel 不加入：
+
+- `IModel`
+- `ISystem`
+- `IUtility`
+- `ICommand`
+- `IQuery`
+- `BindableProperty`
+- `TypeEventSystem`
+- `IController`
+
+原因是这些属于业务架构风格，不是 Feature 编排机制。
+
+### 12.2 CoreModules 可吸收状态变更规则
+
+FlowScope 可以在后续 CoreModules 或 template 中提供推荐规则：
+
+```text
+View / MonoBehaviour
+  -> Command / UseCase / Service Method
+  -> State Service / Feature Local State
+  -> Event / Observable
+  -> View / Presenter / Controller
+```
+
+这能吸收 QFramework 的优点，同时避免 Kernel 被业务范式锁死。
+
+### 12.3 Events 模块可参考 TypeEventSystem，但要补足边界
+
+如果 FlowScope 做 P1 Events，不建议只复制 `TypeEventSystem`。至少要明确：
+
+- 事件作用域：Root-scoped 还是 Feature-scoped。
+- 订阅句柄如何进入 FeatureLifetime。
+- 事件处理异常是否聚合、记录或继续派发。
+- 是否支持异步事件。
+- 是否允许跨 Feature 事件。
+- 是否提供调试追踪。
+
+QFramework 的 TypeEventSystem 可作为最小同步事件模型参考，但不是最终模块规格。
+
+### 12.4 State 模块可参考 BindableProperty，但不要裸露可写状态
+
+如果 FlowScope 提供类似 BindableProperty 的能力，建议区分：
+
+```text
+IReadonlyState<T>
+IMutableState<T>
+StateWriter<T>
+StateChanged<T>
+```
+
+UI 层优先拿只读接口，写入通过 UseCase/Command/Service。这样比直接把 `BindableProperty<T>` 暴露给所有人更稳。
+
+### 12.5 业务模板可以提供 QFramework 风格
+
+可以考虑后续提供一个可选模板：
+
+```text
+FlowScope.BusinessArchitecture
+  - ICommand
+  - ICommand<TResult>
+  - IQuery<TResult>
+  - IUseCase
+  - IStateService
+  - IEventPublisher
+```
+
+但这应是项目选择，不是 Kernel 强制。
+
+## 13. 风险清单
+
+如果直接照搬 QFramework Core 到 FlowScope，主要风险是：
+
+1. Kernel 变成业务架构框架，失去机制最小化。
+2. `Architecture<T>.Interface` 和 `RootScope` 形成双全局入口。
+3. `IOCContainer` 无法表达 FeatureScope 生命周期。
+4. Command/Event 进入 Kernel 后，P1/P2 模块会被迫统一业务风格。
+5. EventBus 变成隐式跨 Feature 通道，削弱 FeatureHost 的显式编排边界。
+6. BindableProperty 进入底层后，UI/状态响应式会反向污染 Kernel。
+
+规避方式：
+
+- Kernel 只保留生命周期、依赖边界、Feature 编排。
+- QFramework 的分层规则只进入文档、模板或可选模块。
+- Event/State/Command 都作为 CoreModules 或扩展层设计。
+- FeatureContext 不提供全能业务能力。
+
+## 14. 结论
+
+QFramework Core 是一个优秀的轻量 Unity 业务架构样本。它用很少代码表达了三条关键规则：
+
+- 上层驱动下层。
+- 状态变更有入口。
+- 下层通过通知影响上层。
+
+FlowScope 应吸收这些规则，但不能把 QFramework 的 Core 形态直接变成自己的 Kernel。FlowScope Kernel 的目标更底层：它负责应用启动、依赖 Scope、Feature 生命周期、运行槽和释放链。QFramework 风格更适合作为 FlowScope 的可选业务层、示例模板或 P1/P2 模块设计参考。
+
+最终边界建议：
+
+```text
+FlowScope.Kernel
+  只负责机制
+
+FlowScope.CoreModules
+  提供 Events / State / Config / Save / Resources / UI 等模块
+
+FlowScope.BusinessTemplate.QFrameworkLike
+  可选提供 Command / Query / State / Event 的业务写法参考
+```
+
+这样既能保留 QFramework 的轻量分层优点，又不会牺牲 FlowScope 当前“Kernel tiny, modules optional”的主方向。

docs/reviews/2026-06-12-uframe-mvvm-core-analysis.md

@@ -0,0 +1,473 @@
+# uFrame MVVM Core 分析
+
+日期：2026-06-12
+
+## 结论
+
+uFrame MVVM 的核心价值不在它的 Kernel、IOC 启动或代码生成器，而在运行时 MVVM 的几个机制：
+
+- `ViewModel` 持有可观察状态。
+- `P<T>` 把 ViewModel 属性包装成可订阅的数据流。
+- `Signal<TCommand>` 把 UI 操作表达成命令流。
+- `ViewBase` 通过 `Bind / Unbind` 管理订阅生命周期。
+- `ViewService` 负责把 View 与 ViewModel 对接。
+
+但这套 MVVM 被 uFrame 自身的全局 Kernel、全局容器、命名约定、`Resources.Load` 和设计器生成代码强绑定。它可以作为反面边界样本和局部机制参考，不适合作为 FlowScope Kernel 或 UI 模块的直接原型。
+
+FlowScope 可以吸收“可观察状态 + 命令流 + 绑定生命周期作用域”，但不应吸收它的全局 IOC 查找、ViewModel 自动解析、Controller 命名约定和资源自动定位。
+
+## 源码范围
+
+本次分析基于 `uFrame/uFrame.MVVM` 当前公开仓库源码，重点阅读：
+
+- [`ViewModel.cs`](https://github.com/uFrame/uFrame.MVVM/blob/master/uFrame.MVVM/Source/Runtime/ViewModels/ViewModel.cs)
+- [`ModelPropertyBase.cs`](https://github.com/uFrame/uFrame.MVVM/blob/master/uFrame.MVVM/Source/Runtime/ViewModels/ModelPropertyBase.cs)
+- [`Signal.cs`](https://github.com/uFrame/uFrame.MVVM/blob/master/uFrame.MVVM/Source/Runtime/ViewModels/Signal.cs)
+- [`ViewBase.cs`](https://github.com/uFrame/uFrame.MVVM/blob/master/uFrame.MVVM/Source/Runtime/Views/ViewBase.cs)
+- [`View.cs`](https://github.com/uFrame/uFrame.MVVM/blob/master/uFrame.MVVM/Source/Runtime/Views/View.cs)
+- [`Controller.cs`](https://github.com/uFrame/uFrame.MVVM/blob/master/uFrame.MVVM/Source/Runtime/Controllers/Controller.cs)
+- [`ViewService.cs`](https://github.com/uFrame/uFrame.MVVM/blob/master/uFrame.MVVM/Source/Runtime/Services/ViewService.cs)
+- [`MVVMKernelExtensions.cs`](https://github.com/uFrame/uFrame.MVVM/blob/master/uFrame.MVVM/Source/Runtime/MVVMKernelExtensions.cs)
+- [`ViewBindings.cs`](https://github.com/uFrame/uFrame.MVVM/blob/master/uFrame.MVVM/Source/Runtime/Bindings/ViewBindings.cs)
+- [`ViewResolver.cs`](https://github.com/uFrame/uFrame.MVVM/blob/master/uFrame.MVVM/Source/Runtime/Views/ViewResolver.cs)
+
+## 运行时结构
+
+uFrame MVVM 的运行时可以拆成五组对象：
+
+```text
+ViewModel 层
+  ViewModel
+  P<T>
+  ModelCollection<T>
+  Signal<TCommand>
+  ViewModelCommand
+
+View 层
+  ViewBase
+  View<TModel>
+  ViewComponent
+  ViewBindings
+
+创建与连接层
+  Controller
+  ViewService
+  ViewResolver
+
+绑定层
+  Binding
+  ModelPropertyBinding
+  ModelViewPropertyBinding
+  ModelViewModelCollectionBinding
+
+全局基础设施
+  uFrameKernel.Container
+  IEventAggregator
+  SystemService / SystemServiceMonoBehavior
+```
+
+它不是一个独立、纯粹的 MVVM runtime。`ViewModel`、`View`、`Controller` 和 `ViewService` 都会触碰 uFrame Kernel 或全局容器。
+
+## ViewModel
+
+`ViewModel` 是所有生成 ViewModel 的基类。它承担了状态、绑定、序列化、事件发布、销毁通知等多种职责。
+
+关键职责：
+
+- 通过 `FillProperties` 暴露属性元信息。
+- 通过 `FillCommands` 暴露命令元信息。
+- 持有 `Bindings`，用于释放订阅。
+- 持有 `Identifier`，用于全局容器按 id 查找。
+- 通过 `PropertyChanged` 通知属性变化。
+- `Dispose` 时发布 `ViewModelDestroyedEvent`。
+
+问题是它太重。一个干净的 ViewModel 应该主要表达 UI 状态和 UI 意图，但这里的 `ViewModel` 混入了：
+
+- 序列化协议。
+- `IBindable`。
+- `IDisposable`。
+- 全局事件聚合器。
+- binding 容器。
+- 引用计数。
+- controller wiring hook。
+
+这会让 ViewModel 从“状态对象”变成“框架对象”。长期项目里，这种设计会让测试、复用和生命周期判断都变复杂。
+
+## P<T>
+
+`P<T>` 是 uFrame MVVM 最值得看的部分。它把单个属性封装成 observable property：
+
+```csharp
+public class P<T> : ISubject<T>, IObservableProperty, ISimpleNotifyPropertyChanged
+```
+
+它提供：
+
+- `Value`：当前值。
+- `LastValue`：上一次值。
+- `ChangedObservable`：只在值变化时通知。
+- `ObjectValue`：非泛型访问入口。
+- `Owner`：所属 ViewModel。
+- `PropertyName`：属性名。
+- `ToComputed`：根据其他 observable property 计算派生值。
+
+View 侧可以订阅 `P<T>`，属性变化时刷新 UI。这个机制适合 Unity UI，因为它避免了大量手动 `Refresh()` 和每帧轮询。
+
+可取点：
+
+- 属性变化可以显式订阅。
+- 派生属性可以声明依赖。
+- View 绑定时可以立即应用当前值。
+- IDisposable 可以挂到绑定作用域统一释放。
+
+风险点：
+
+- `Value` setter 没有先比较新旧值，任何赋值都会触发通知。
+- `Owner` 让 property 反向知道 ViewModel。
+- `P<T>` 同时实现 subject、property、notify，职责偏多。
+- `ChangedObservable` 依赖 `Value` 和 `LastValue` 的外部状态，语义不够直观。
+
+FlowScope 如果吸收这个思路，应改成更小的 `ObservableProperty<T>`：
+
+```text
+只负责保存值、比较值、发布变化、释放订阅。
+不要知道全局 Kernel。
+不要知道 View。
+不要知道资源或 Controller。
+```
+
+## Signal<TCommand>
+
+`Signal<TCommand>` 用来表达 ViewModel 命令：
+
+```csharp
+public class Signal<TClass> : ISubject<TClass>, ISignal<TClass>
+    where TClass : IViewModelCommand, new()
+```
+
+它的行为是：
+
+1. View 或绑定层构造 command。
+2. 调用 `Signal.OnNext(command)`。
+3. `Signal` 把 `Sender` 设置为当前 ViewModel。
+4. 执行本地 `Action`。
+5. 推送给订阅者。
+
+这个方向是好的：UI 操作不应该直接调用业务系统，而应该变成可观察的 command 或 intent。
+
+可取点：
+
+- UI 输入被建模为显式命令。
+- 命令可以订阅、组合、测试。
+- View 与业务处理之间不需要直接互相引用。
+
+风险点：
+
+- command 的 sender 被 `Signal` 自动写入，有隐式副作用。
+- 命令流最终仍然容易接到全局 EventAggregator。
+- 生成器会为每个命令生成强约定代码，手写维护成本高。
+
+FlowScope 可以吸收 command stream，但建议命名为更中性的 `UIIntent` / `ViewAction` / `FeatureCommand`，并放在 feature scope 内，不进入 Kernel core。
+
+## ViewBase / View<TModel>
+
+`ViewBase` 是 View 与 ViewModel 的连接点。它提供：
+
+- `ViewModelObject`：当前绑定的 ViewModel。
+- `Bind()`：用户编写订阅逻辑。
+- `PreBind()`：生成器插入绑定逻辑。
+- `AfterBind()`：绑定完成后的 hook。
+- `Unbind()`：释放绑定。
+- `AddBinding()`：把 disposable 放到当前 View 的绑定列表。
+- `BindOnStart`：是否启动时自动绑定。
+- `DisposeViewModelOnDestroy`：View 销毁时是否销毁 ViewModel。
+
+`View<TModel>` 只是给 `ViewBase` 加了泛型 Model 访问：
+
+```csharp
+public abstract class View<TModel> : ViewBase where TModel : ViewModel, new()
+```
+
+可取点：
+
+- View 的绑定逻辑有明确生命周期。
+- 订阅统一挂到 binding scope。
+- View 只响应 ViewModel 的状态，不需要每帧刷 UI。
+- View 销毁时可以集中释放订阅。
+
+问题点：
+
+- `ViewBase.KernelLoaded()` 会调用 `uFrameKernel.Container.Inject(this)`。
+- `OnDestroy()` 依赖 `uFrameKernel.IsKernelLoaded` 和全局事件。
+- View 的 `Bindings` 实际挂在 `ViewModelObject.Bindings[ViewId]` 上，View 和 ViewModel 的生命周期互相缠住。
+- `References` 引用计数用于判断 ViewModel 是否销毁，复杂且脆弱。
+
+FlowScope 可以借鉴 `Bind / Unbind / AddBinding`，但绑定容器应属于 View 或 feature-local binding scope，而不是塞进 ViewModel。
+
+## Controller
+
+uFrame 的 `Controller` 是特殊的 `SystemService`，主要负责创建和初始化 ViewModel。
+
+流程大致是：
+
+```text
+Controller.Create(identifier)
+  -> CreateEmpty(identifier)
+  -> RegisterViewModel(vm, identifier)
+  -> Initialize(vm)
+  -> Publish ViewModelCreatedEvent
+```
+
+问题在于 `CreateEmpty` 内部直接注册到全局容器：
+
+```text
+uFrameKernel.Container.RegisterViewModel(vm, identifier)
+```
+
+`MVVMKernelExtensions.CreateViewModel(type)` 又会通过 ViewModel 类型名去全局容器找 Controller：
+
+```text
+Resolve<Controller>(type.Name)
+```
+
+这是强命名约定 + 服务定位器。它表面上把 ViewModel 创建集中到了 Controller，实际上把依赖关系藏进全局容器和类型名字符串。
+
+FlowScope 不应该吸收这套 Controller 模式。更合适的是：
+
+```text
+Feature 明确创建 ViewModel。
+Feature 明确创建/绑定 View。
+FeatureContext 提供本 feature 需要的服务。
+UI module 不通过全局容器按名字找 Controller。
+```
+
+## ViewService / ViewResolver
+
+`ViewService` 负责：
+
+- 监听 `InstantiateViewCommand`。
+- 根据 ViewModel 找 View prefab。
+- 实例化 View。
+- 在 View 创建时补齐 ViewModel。
+- View 销毁时移除记录。
+- ViewModel 销毁时从全局容器移除实例。
+
+`ViewResolver` 默认根据 ViewModel 类型名找 prefab：
+
+```text
+PlayerViewModel -> Player -> Resources.Load("Player")
+```
+
+这是老式 Unity 框架常见做法，但不适合 FlowScope：
+
+- 资源路径是隐式命名约定。
+- 默认绑定到 `Resources.Load`。
+- 不支持现代资源后端的显式 handle、group、release。
+- 不利于 Addressables / YooAsset / AssetBundle / 自定义资源系统适配。
+- View 的创建和 ViewModel 的创建混在同一个服务里。
+
+FlowScope 如果需要 UI 模块，可以把它拆成：
+
+```text
+IViewFactory
+  负责创建 View，不负责创建 ViewModel。
+
+IViewBinder<TView, TViewModel>
+  负责绑定和解绑。
+
+IUIViewRegistry 或 IViewCatalog
+  负责显式注册 view key 到 prefab/address。
+
+IResourceService adapter
+  负责真实资源加载和释放。
+```
+
+## Binding
+
+uFrame 的 binding 层包括：
+
+- `Binding`
+- `ModelPropertyBinding`
+- `ModelViewPropertyBinding`
+- `ModelViewModelCollectionBinding`
+- `ViewBindings` 扩展方法
+
+最实用的是 `ViewBindings.BindProperty`：
+
+```text
+立即用当前值刷新一次 UI。
+订阅后续变化。
+把 IDisposable 加入 bindable 的绑定列表。
+```
+
+这是 FlowScope 可以吸收的重点：
+
+```csharp
+bindingScope.Bind(vm.Title, value => titleText.text = value);
+```
+
+但不要吸收它的反射绑定和生成器绑定作为 core。反射/生成器可以是工具层能力，不应该成为 UI runtime 的基本前提。
+
+## 与 FlowScope Kernel 的关系
+
+uFrame MVVM 不应该进入 FlowScope Kernel core。
+
+FlowScope Kernel 已经明确应保持机制小核：
+
+```text
+Container
+AppKernel
+StartupPipeline
+FeatureHost
+FeatureInstance
+FeatureContext
+FeatureLifetime
+FeatureSlot
+FeaturePolicy
+```
+
+MVVM 属于更高层的 UI module 或 feature-local module。Kernel 最多提供 feature 生命周期和上下文，不提供：
+
+- ViewModel 基类。
+- View 自动绑定。
+- UI prefab 查找。
+- 命令总线。
+- 全局 ViewService。
+- 全局事件聚合器。
+- 全局 IOC 注入 View。
+
+推荐边界：
+
+```text
+FlowScope.Kernel
+  只负责 Feature 生命周期和 Slot/Policy 机制。
+
+FlowScope.UI
+  提供 ViewModel、ObservableProperty、BindingScope、ViewBinder。
+
+FlowScope.Resources
+  提供资源加载接口和后端适配。
+
+Game Feature
+  自己声明 ViewModel、View、Binder、Command handler。
+```
+
+## 可吸收清单
+
+可以吸收：
+
+- `ObservableProperty<T>` 思路。
+- `ObservableCollection<T>` 思路。
+- UI command / intent stream。
+- `Bind / Unbind` 生命周期。
+- `IDisposable` binding scope。
+- View 订阅 ViewModel，ViewModel 不直接操作 View。
+- View 创建和 ViewModel 绑定分离。
+- 集合绑定生成子 View 的思路，但要显式管理资源释放。
+
+不应吸收：
+
+- `uFrameKernel.Container` 全局创建 ViewModel。
+- `Container.Inject(view)`。
+- 按 `ViewModel` 类型名查找 `Controller`。
+- 按 `ViewModel` 类型名 `Resources.Load` prefab。
+- ViewModel 持有 View 绑定列表。
+- ViewModel 引用计数决定销毁。
+- 全局 EventAggregator 作为 UI command 默认通道。
+- 代码生成器作为 runtime 必需条件。
+- ViewModel 同时承担序列化、绑定、事件、销毁、controller hook。
+
+## FlowScope 可采用的最小 UI MVVM 形态
+
+建议的最小形态：
+
+```text
+ObservableProperty<T>
+  保存值并发布变化。
+
+BindingScope
+  持有 IDisposable 列表，Dispose 时统一释放。
+
+IViewModel
+  标记 UI 状态对象，不依赖 Kernel。
+
+IViewBinder<TView, TViewModel>
+  Bind(view, vm, scope)
+  Unbind 由 scope.Dispose 承担。
+
+UIView<TViewModel>
+  MonoBehaviour，只持有 Unity UI 引用和当前 ViewModel。
+
+UICommand<T>
+  feature-local command，不走全局事件总线。
+```
+
+示意：
+
+```csharp
+public sealed class BindingScope : IDisposable
+{
+    private readonly List<IDisposable> _items = new();
+
+    public T Add<T>(T item) where T : IDisposable
+    {
+        _items.Add(item);
+        return item;
+    }
+
+    public void Dispose()
+    {
+        foreach (var item in _items)
+            item.Dispose();
+
+        _items.Clear();
+    }
+}
+```
+
+```csharp
+public sealed class MainMenuViewModel
+{
+    public ObservableProperty<string> Title { get; } = new("Main Menu");
+    public Subject<StartGameIntent> StartGame { get; } = new();
+}
+```
+
+```csharp
+public sealed class MainMenuBinder
+{
+    public void Bind(MainMenuView view, MainMenuViewModel vm, BindingScope scope)
+    {
+        scope.Bind(vm.Title, value => view.TitleText.text = value);
+        scope.Add(view.StartButton.OnClickAsObservable()
+            .Subscribe(_ => vm.StartGame.OnNext(new StartGameIntent())));
+    }
+}
+```
+
+关键点是：这里没有全局容器查找，没有 `Resources.Load` 约定，没有 Kernel 注入 View，也没有 ViewModel 引用计数。
+
+## 最终判断
+
+uFrame MVVM 的局部机制比它的 Kernel 更有参考价值，但必须拆开看。
+
+真正值得保留的是：
+
+```text
+状态可观察
+操作命令化
+绑定有生命周期
+View 不直接写业务
+```
+
+必须避免的是：
+
+```text
+全局容器创建一切
+命名约定连接一切
+ViewModel 变成框架对象
+资源加载隐藏在 ViewResolver
+UI 模块污染 Kernel core
+```
+
+对 FlowScope 来说，uFrame MVVM 最好的用途不是成为模板，而是提醒我们：UI MVVM 应该是 Kernel 之上的可选模块，且必须保持 feature-local、显式绑定、显式资源、显式生命周期。