根本原因是响应式系统未就绪时访问 computed，导致 undefined 报错；常见于 setup 早期、微任务中过早读取；应延迟至 onMounted、用 ref 缓存或封装安全读取函数。
这个问题本质是“在响应式系统尚未建立完成时，就尝试读取计算属性”，常见于组件初始化早期、异步 setup 或微任务（如 Promise.then、queueMicrotask）中过早访问 computed。它不报死循环，但会抛出 Cannot read properties of undefined 或直接 TypeError，因为此时 computed 还未被 Vue 初始化，getter 根本没挂载，this.xxxComputed 是 undefined。
确认是否处于“computed 尚未就绪”的阶段
Vue 的 computed 在组件实例创建后、setup() 执行完毕、响应式代理建立完成时才真正可用。以下场景极易踩坑：
- 在
onBeforeMount之前、甚至setup()返回前，用queueMicrotask(() => console.log(this.fullName)) - 在
ref或reactive初始化后立刻调用nextTick或Promise.resolve().then，并在此回调里读 computed - 使用
defineComponent+setup时，把 computed 定义在条件分支里（如if (props.lazy) { const x = computed(...) }），却在外部无保护地引用
安全读取 computed 的三类做法
核心原则：**不假设 computed 已存在，始终做存在性判断或延迟到确定就绪后再读**。
-
显式等待响应式就绪：在
onMounted或onActivated钩子中读取 —— 这是最稳妥的时机，确保整个 setup 和依赖收集已完成 -
用 ref 缓存 + 条件访问：定义一个
const fullNameRef = ref()，在 computed 创建后立即赋值，并在微任务中只读该 ref：queueMicrotask(() => fullNameRef.value && doSomething(fullNameRef.value)) -
封装防错读取函数：写一个工具函数，内部用
try/catch+ 可选链，例如：
const safeRead = (getter) => { try { return getter?.() ?? null; } catch { return null; } };
然后queueMicrotask(() => safeRead(() => this.fullName))
避免在 setup 中提前触发微任务链
很多人在 setup() 开头就写：Promise.resolve().then(() => console.log(computedValue)) —— 此时 computedValue 可能连声明都还没执行完（尤其当 computed 定义在后面几行）。正确顺序应是：
- 先完整声明所有响应式数据（ref/reactive/computed）
- 再统一安排副作用逻辑（如事件监听、定时器、微任务调度）
- 若必须在 setup 内调度，改用
nextTick（它等 DOM 更新队列清空，也隐含响应式就绪）而非裸 Promise
TS 用户特别注意类型断言风险
即使你写了 const fullName = computed，TypeScript 的类型检查无法阻止运行时 fullName 是 undefined —— 因为它只是个函数引用，不是值本身。不要依赖类型推导来跳过空值校验。建议配合非空断言（!）时加注释说明前提，或直接用可选链：fullName?.value（注意 computed 对象有 .value 属性）。
