hot_patch library
hot_patch —— Flutter 热更新运行时包。
面向「线上出 bug → 运行时切换到 JS 补丁修复」的场景：
构建期由 hot_patch_generator 把带注解的正常 widget 静态翻译成
同名 .js（与 dart 源文件对应），运行时用 JsUiWidget
加载 JS 补丁渲染组件、由 JS 驱动逻辑。
渲染入口是 JsUiWidget（宿主）+ JS 侧 __jsui 运行时（element /
component / reconciler / context / commit 协议）；每一项能力——无论
Flutter 等价物（Key / 各 Controller / BuildContext 代理 /
NotificationListener）还是三方状态库（provider / GetX / …）——都通过
JsUiLibrary 子类接入；宿主只做「JS 结点 → Flutter widget」映射
（JsWidgetRegistry）+ 增量补丁应用（JsUiStore）。
接入一个新能力：继承 JsUiLibrary 重写需要的钩子，再
registerJsUiLibrary(...)（内建能力见 capabilities/js_ui_library.dart 的
_seedBuiltins；也可在 App 的 main() 里注册，从而完全不改本包）。
宿主核心文件零改动。
JS→原生能力统一走「宿主方法」：JS 侧唯一出口 _app_host_.invoke，宿主侧唯一
入口 JsRuntimeManager.registerHostMethod（业务方法用 @HostInjected 注解
由生成器注册，框架内建通道由 JsUiWidget 启动时注册），核心类零改动。
Classes
- JsRenderContext
- 不需要动宿主；只有引入 Flutter 侧不存在的视觉 widget 才注册一条。
- JsRuntimeManager
-
JS 运行时管理器：与底层
JavascriptRuntime一对一。 每个 JsRuntimeManager 内部持有一个JavascriptRuntime，所有与 JavascriptRuntime 相关的操作（创建、求值、通道注册、生命周期）都在 本类内部消化；JsUiWidget 等使用方只接触 JsRuntimeManager， 完全不感知底层运行时对象。 - JsUiWidget
- JS-UI 页面的宿主入口。
- JsUiWidgetState
- JsWidgetRegistry
-
type -> Flutter widget注册表（宿主唯一扩展点）。
Functions
-
buildJsElement(
Object? raw, void invoke(Object? handler, [List< Object?> args])) → Widget? -
把产物里的元素描述（
{type, props, children, element}）渲染成 widget。 -
buildMissingJsWidget(
String type, List< Widget> children) → Widget - 元素 type 未注册（既无宿主 builder、也无原生注入实现）时，给出可见占位。
-
isJsDataCarrierType(
String type) → bool - 该类型是否登记为非 Widget 数据载体（类型表驱动，不做类型名硬编码判断）。
-
registerBuiltinJsWidgets(
JsWidgetRegistry r) → void - 注册内置的宿主 widget 翻译。
-
registerJsDataCarrierType(
String type) → void - 登记一个「非 Widget 数据载体」类型。
-
registerNativeComponent(
String name, Widget build(Map< String, dynamic> args)) → void -
注册一个「无 JS 产物组件」的原生实现（如生成器对
@PatchIgnore/ 无注解私有组件产出的「保留具体类型名」结点）。
Typedefs
- JsWidgetBuilder = Widget Function(JsRenderContext c)