理解一个复杂 Vue 界面，最有效的方法往往不是先看目录，而是挑一次真实交互：用户点了什么，画面哪里改变，状态写到了哪里，最后有没有发出请求。沿着这条线走，架构会自己显现。

从屏幕上的变化开始

假设用户在选择器里勾选了一个选项。最先发生的是组件发出更新事件，父层或上下文把值写进响应式数据模型，依赖这个路径的视图随之重新计算。到这里为止，一切都可以只在浏览器本地完成。

先问“屏幕上什么变了”，再问“哪个抽象负责它”。具体行为是理解架构最可靠的入口。

状态路径就是组件之间的契约

当组件通过明确路径读写数据时，它不需要知道整个页面结构。选择器只关心自己的 value，Renderer 负责把这个 value 映射到数据模型。这个间接层看似多了一步，却让同一个组件能够安全出现在不同表面。

ChoicePicker.value
  ↔ /selection

TextField.value
  ↔ /customInput

点击确认之后

只有当用户点击确认，局部状态才被整理成 Action context。Renderer 校验动作是否在当前能力范围内，宿主再决定使用哪条传输通道。此时的 payload 是一次明确意图，而不是一串难以追踪的零散输入事件。

这条路径也提示了一种更好的代码解释方式：展示初始数据，展示点击后的数据，再展示最终发送的 Action。三张快照通常比一张宏大的架构图更容易建立直觉。

用一个 Vue 3 例子固定状态归属

下面是父组件的最小示意。ChoicePicker 需要接收 modelValue，并通过 update:modelValue 事件通知父层；confirm 只是本地事件，不隐含任何网络协议。

<script setup lang="ts">
import { ref } from "vue";
import ChoicePicker from "./ChoicePicker.vue";

const selectedId = ref("");
const emit = defineEmits<{
  confirm: [payload: { selectedId: string }];
}>();

function confirm() {
  if (!selectedId.value) return;
  emit("confirm", { selectedId: selectedId.value });
}
</script>

<template>
  <ChoicePicker v-model="selectedId" />
  <button :disabled="!selectedId" @click="confirm">确认</button>
</template>

这里的单一事实来源是父层 selectedId。子组件可以管理焦点、展开状态等展示细节，但不应该再维护一份永远需要与父层同步的正式选中值。嵌入生成式界面时，由适配层把更新事件映射到 Surface 数据路径，不要让普通选择器直接依赖聊天传输通道。

三个快照定位故障

时刻应该观察什么异常时优先检查
初始渲染selectedId 与控件选中态一致props 与绑定路径
改变选择父层值更新，界面重绘事件名称、响应式连接
点击确认事件携带当前 ID旧闭包、错误 Surface 上下文

如果本地值正确而请求参数错误，继续追宿主动作适配；如果服务端接受请求但结果不刷新，检查响应写回和请求竞态。不要一看到画面不动就先强制重建组件，那会掩盖状态路径的问题，并丢掉用户输入。

继续阅读