一，Vue3 的 Composition API 相比 Options API，在大型项目中解决了哪些核心问题？结合实际场景说明。

核心解决的问题：

1. 逻辑复用与聚合：解决 Options API 中 “逻辑分散在 data、methods、watch 等选项中” 的问题，实现相关逻辑的集中管理。
2. 类型推导友好：天然支持 TypeScript，避免 Options API 中 this 指向模糊导致的类型校验困难。
3. 代码可维护性：大型项目中逻辑复杂度高，Composition API 通过 “按功能拆分代码” 替代 “按选项拆分”，降低理解成本。

实际场景：

1. 逻辑聚合：解决 “跨选项逻辑碎片化” 问题

会诊系统的核心模块（如 “实时会诊会话”）往往包含多重关联逻辑：

• 会话状态管理（连接 / 断开 / 重连）；
• 音视频流控制（开启 / 关闭 / 切换设备）；
• 消息同步（实时聊天、系统通知）；
• 权限校验（主持人 / 参会人操作限制）。

用 Options API 实现时，这些逻辑会被拆分到 data（定义 isConnected currentStream 等变量）、methods（定义 connect() toggleAudio() 等方法）、watch（监听连接状态变化）、mounted（初始化连接）中。当需要修改 “网络断开时自动重连并暂停音视频” 的逻辑时，需在 watch（监听断开事件）、methods（重连方法）、data（重连次数变量）间反复跳转，代码关联性被选项割裂。

而 Composition API 可按 “功能模块” 聚合逻辑：

// 会话连接逻辑
function useSessionConnection(roomId) {
  const isConnected = ref(false);
  const reconnectCount = ref(0);
  const connect = () => { /* 连接逻辑 */ };
  const handleDisconnect = () => { /* 断开处理+重连 */ };
  onMounted(connect);
  return { isConnected, handleDisconnect };
}

// 音视频控制逻辑
function useMediaStream() {
  const audioEnabled = ref(true);
  const toggleAudio = () => { /* 切换音频 */ };
  const pauseAllStreams = () => { /* 暂停所有流 */ };
  return { audioEnabled, toggleAudio, pauseAllStreams };
}

// 组件中聚合调用
setup(props) {
  const { isConnected, handleDisconnect } = useSessionConnection(props.roomId);
  const { pauseAllStreams } = useMediaStream();
  
  // 网络断开时自动暂停音视频
  watch(isConnected, (newVal) => {
    if (!newVal) pauseAllStreams();
  });
  return { ... };
}

相关逻辑集中在独立函数中，修改时无需跨选项查找，尤其适合多人协作维护（新开发者可直接定位到 useSessionConnection 理解连接逻辑）。

2. 逻辑复用：解决 “mixin 冲突与来源模糊” 问题

会诊系统中，“消息通知” 功能（如收到新消息时弹窗、播放提示音）需在多个组件（会诊室、聊天面板、医生列表）中复用。

用 Options API 的 mixin 实现时，可能出现：

• 变量冲突：mixin 中定义的 unreadCount 与组件内同名变量冲突；
• 来源模糊：组件中调用 playNotifySound() 时，无法快速定位该方法是来自 mixin 还是组件自身。

而 Composition API 的 use 函数模式可明确复用逻辑的来源：

// 复用的消息通知逻辑
export function useMessageNotify() {
  const unreadCount = ref(0);
  const playNotifySound = () => { /* 播放提示音 */ };
  const showNotify = (msg) => { /* 显示弹窗 */ };
  return { unreadCount, playNotifySound, showNotify };
}

// 在会诊室组件中使用
import { useMessageNotify } from './useMessageNotify';
setup() {
  const { unreadCount, showNotify } = useMessageNotify();
  // 清晰知道方法来自 useMessageNotify，无冲突风险
  return { unreadCount, showNotify };
}

3. 类型友好：解决 “this 指向模糊导致的 TS 适配困难” 问题

医疗系统对类型安全要求极高（如会诊数据的字段校验）。Options API 中，this 指向组件实例，但 TS 无法精准推断 this 上的属性类型（如 this.roomId 可能被误判为 any），需手动声明 interface 适配，维护成本高。

Composition API 基于函数参数和返回值，天然支持 TS 类型推导：

// 定义会诊房间类型
interface ConsultRoom {
  id: string;
  status: 'waiting' | 'inProgress' | 'ended';
}

// 类型自动推导：room 为 ConsultRoom 类型
function useRoomStatus(room: ConsultRoom) {
  const isInProgress = computed(() => room.status === 'inProgress');
  return { isInProgress };
}

// 组件中传入类型错误时，TS 直接报错（如传入 number 类型的 id）
setup() {
  const room = ref<ConsultRoom>({ id: '123', status: 'waiting' });
  const { isInProgress } = useRoomStatus(room.value);
}

总结：在会诊系统这类逻辑复杂、复用需求高、类型安全要求严的大型项目中，Composition API 通过 “逻辑聚合、明确复用、类型友好” 三大特性，显著降低了代码维护成本和出错风险，这是 Options API 难以比拟的。

二，在会诊系统中，如何利用 Vue3 的provide/inject实现跨层级组件通信？相比 Vue2 的eventBus有哪些优势？

实际场景：会诊系统中，存在多层级嵌套组件：App（根组件）→ ConsultationRoom（会诊房间）→ DoctorList（医生列表）→ DoctorCard（医生卡片）→ MicControl（麦克风控制按钮）。需要实现：所有医生的麦克风状态（开 / 关）需实时同步到根组件的全局状态面板，且根组件能强制关闭所有麦克风（如主持人静音功能）。

实现方案：

1. 在根组件App中通过provide提供全局状态和方法：

   // App.vue
   import { provide, reactive } from 'vue';
   export default {
     setup() {
       // 全局麦克风状态：key为医生ID，value为是否静音
       const micState = reactive({});
       
       // 提供状态和修改方法
       provide('mic', {
         state: micState,
         setMic: (doctorId, isMuted) => {
           micState[doctorId] = isMuted;
         },
         muteAll: () => {
           Object.keys(micState).forEach(id => (micState[id] = true));
         }
       });
     }
   };

2. 在深层级的MicControl组件中通过inject获取并使用：

   // MicControl.vue
   import { inject } from 'vue';
   export default {
     props: ['doctorId'],
     setup(props) {
       const mic = inject('mic');
       const toggleMic = () => {
         mic.setMic(props.doctorId, !mic.state[props.doctorId]);
       };
       return { toggleMic, isMuted: () => mic.state[props.doctorId] };
     }
   };

3. 在根组件的全局面板中调用muteAll实现强制静音：

   // App.vue的全局面板组件
   const mic = inject('mic');
   const handleMuteAll = () => mic.muteAll();

   相比 Vue2 的 eventBus 的优势：

4. 类型安全：provide/inject可配合 TypeScript 定义类型，避免 eventBus 中事件名拼写错误（如mic-change写成mic-chang）导致的隐式 Bug。
5. 状态溯源清晰：全局状态集中在provide处管理，而非分散在各组件的$emit中，会诊系统中若麦克风状态异常，可直接定位到根组件的setMic方法排查。
6. 避免事件冒泡混乱：多层级通信时，eventBus 需手动传递事件（如DoctorCard→DoctorList→ConsultationRoom→App），而provide/inject直接跨层级访问，减少中间组件的冗余代码

三，会诊系统中存在大量实时数据（如医生在线状态、消息通知、音视频流状态），如何利用 Vue3 的响应式系统优化性能？

实际场景：会诊系统的 “实时监控面板” 需要展示：

• 20 + 医生的在线状态（在线 / 离线 / 发言中）；
• 实时消息列表（每秒可能新增多条）；
• 音视频流的码率、延迟等指标（高频更新）。若直接渲染会导致组件频繁更新，出现页面卡顿。

优化方案：

1. 使用shallowRef/shallowReactive减少深层代理：医生在线状态数据结构为{ id: 'doc1', status: 'online', details: { ... } }，其中details是不参与渲染的冗余信息。用shallowReactive只代理第一层属性，避免深层对象的不必要代理：

   // 只监听status的变化（第一层属性），忽略details的修改
   const doctors = shallowReactive({
     'doc1': { status: 'online', details: { ... } },
     'doc2': { status: 'offline', details: { ... } }
   });

   通过computed缓存派生数据，避免重复计算：实时消息列表需过滤出 “未读消息” 并排序，用computed缓存结果，仅在源数据变化时重新计算：

   const messages = ref([]); // 原始消息列表
   // 缓存未读消息，避免每次渲染都执行过滤排序
   const unreadMessages = computed(() => {
     return messages.value
       .filter(msg => !msg.read)
       .sort((a, b) => b.timestamp - a.timestamp);
   });

   用v-memo减少列表重复渲染：医生列表组件DoctorList中，每个DoctorCard的渲染依赖status，用v-memo缓存 DOM，仅当status变化时才重新渲染：

   <!-- DoctorList.vue -->
   <div v-for="doc in doctors" :key="doc.id">
     <DoctorCard 
       v-memo="[doc.status]"  <!-- 仅当status变化时更新 -->
       :status="doc.status" 
     />
   </div>

   拆分组件，隔离响应式依赖：音视频指标面板（高频更新）与医生列表（低频更新）拆分为独立组件，避免指标更新时带动整个页面重渲染：

   <!-- 监控面板拆分 -->
   <RealTimeMetrics /> <!-- 高频更新，仅自身重渲染 -->
   <DoctorList />      <!-- 低频更新，不受Metrics影响 -->

   Vue3 的响应式系统通过 Proxy 实现精准依赖收集，但高频 / 大数据场景仍需手动优化 —— 通过 “减少代理深度”“缓存计算结果”“隔离更新范围”，确保实时数据更新时只触发必要的组件渲染，在会诊系统这类对流畅度要求高的场景中尤为重要。