先记住这个答案
Vue 3.4 起 watch 支持 once: true，回调首次运行后侦听器自动停止。默认懒执行时，它等待一次来源变化；若同时设置 immediate，创建时的立即回调已经是首次运行，之后变化不会再得到同一侦听器的回调。手动 stop 可以表达更复杂的条件，例如直到来源满足业务条件才停止，但需要正确处理立即执行、作用域和异步任务的生命周期。
- once 在首次回调运行后停止，不等待业务成功
- immediate 的首次回调也计入 once
- 每次重新创建侦听器都有自己的生命周期
第一次变化与立即执行如何组合
只设置 once 时，watch 仍保留默认懒执行行为，创建时不会先调用业务回调，来源变化后才运行并停止。加上 immediate 则会在创建时运行，因而这次就触发自动停止。不能认为 once 永远只计算创建之后的变化，而把立即回调排除在外。
下面分别创建两类侦听器，并用同步调度观察明确的单次变化。第一个记录从零到一，第二个只记录创建时的零与 undefined。示例没有网络行为，不把这两个回调的停止当作异步任务已经结束。
import { ref, watch } from 'vue';
const value = ref(0);
const lazy: string[] = [];
const eager: string[] = [];
watch(value, (next, previous) => lazy.push(next + '/' + String(previous)),
{ once: true, flush: 'sync' });
watch(value, (next, previous) => eager.push(next + '/' + String(previous)),
{ once: true, immediate: true, flush: 'sync' });
value.value = 1;
value.value = 2;在 Vue 3.5.21 中，lazy 只有 1/0，eager 只有 0/undefined。两个数组都只增加一项，但执行时机不同；代码没有声明控制台输出。
业务条件不一定在第一次回调时满足
如果需要等用户信息中的 ready 首次变成 true 才执行初始化，直接监听整个对象加 once，可能在别的字段先变化时就停止。应让来源与条件准确对应，并明确 false 到 true 的业务含义。需要跳过若干变化再停止时，手动停止或更直接的状态流程更合适。
手动 stop 也有边界：immediate 回调可能在 watch 调用返回句柄之前执行，回调里直接访问尚未初始化的 stop 常量会有时序问题。不要靠一句“把 stop 放进回调”省略这个约束；可以调整首次判断与注册流程，或在需求确实匹配时使用 once。
停止观察不等于异步业务成功
回调返回一个 Promise，并不会让 once 自动理解成功、失败或是否需要重试。侦听器停止还有对应清理语义，回调建立的资源若被清理取消，也需要明确这是否符合预期。对于初始化请求，更应设计加载、错误和重试状态，而不是把 once 当作成功一次后自动完成的任务系统。
组件重新挂载或组合函数再次创建新的侦听器，又会有新的一次回调机会。跨页面统计去重、支付或写入幂等必须由明确标识与服务端协议保证，不能依赖一个前端侦听器曾经停止。验收时要分别覆盖首次创建、后续变化、失败与重新创建。
容易答错的地方
- once 等于全局只调用一次业务接口
- 它只管理当前侦听器的回调次数，新的组件实例可以建立新的侦听器。网络重试、并发入口与远端写入还需要独立的幂等设计。
- once 会等待 async 回调成功后再停止
- 它不把 Promise 成功结果当成业务完成条件。需要成功后停止、失败可重试时，应显式管理状态和句柄，不要把异步协议寄托在一次回调选项上。
面试官还会怎么问？
回调里提前 return 会不会保留下一次机会？
回调已经运行就属于一次调用，不能靠提前 return 把它从 once 次数中撤销。若只想在某个条件满足后停止，应让条件判断与停止策略明确表达。
需要用户首次选中有效项才运行，怎么设计？
先定义什么是有效选择，再选择能表达该状态的来源或事件。用户命令本来就有明确触发点时，也可以直接在事件流程中处理，避免观察无关对象变化。
默认调度下连续改两次一定会记录第一次值吗？
不一定，同步修改可能被批量调度，首次实际回调可能看到本轮合并后的结果。示例特意用 sync 区分逐次变化，业务应按真实调度语义设计。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。