DefaultLayout 骨架与主题通信

概述

基础组件是否真的可复用，不在单独能不能跑，而在放进完整布局后能否协同工作。本节进入后台整体布局层：把菜单、头部工具栏、内容区、主题抽屉组织到同一个 DefaultLayout 中，并解决一个关键工程问题——主题配置到底存在哪一层最合理。同时把菜单系统接到真实文件路由上，处理图标注入、key 稳定性与背景色兼容。

这一节是后面所有布局章节的地基：没有明确「状态该放哪一层、组件间如何通信、布局与业务的边界在哪」，后续的菜单、头部、主题抽屉只会越加越乱。把 DefaultLayout 的角色想清楚，后面每个功能才有明确的归属。

学习目标

• 理解 DefaultLayout 作为局部状态与事件中枢的角色，以及 Sidebar + Header + Main 标准骨架
• 掌握主题配置的存放权衡：默认收在布局层，跨页面持久化时再接 Store
• 用「右侧定位 + translateX 位移动画 + 插槽」封装通用抽屉容器
• 用 provide/inject（配合 InjectionKey）在同一布局树内共享主题与图标样式
• 通过目录同名页面与 definePage() 把菜单接到路由 Meta，并兜住 key 与图标导入稳定性
• 在布局层与业务层之间留出清晰边界，避免基础组件强耦合具体业务或状态库

一、DefaultLayout 作为布局状态中枢

只有把此前做好的菜单、全屏、暗黑、主题按钮真正放进后台布局，才能验证它们的组合效果。DefaultLayout 同时具备足够的层级、覆盖主要受影响区域、又未上升到应用根实例，因此最适合承担：

• 主题状态存储（layoutMode、menuBgColor、darkMode 等）
• 抽屉开关状态
• 菜单模式切换
• 向子组件分发配置

一个判断标准是：如果某个状态会影响菜单、头部、标签页等多个兄弟区域，它就不该塞进其中某一个子组件——菜单只是主题配置的受影响者，不应成为配置存储中心。当前阶段最重要的落点，是把骨架固定为 Sidebar + Header + Main：

<template>
  <div class="layout">
    <aside class="layout-sidebar"><AppMenu /></aside>
    <section class="layout-content">
      <header class="layout-header">
        <FullScreenToggle />
        <DarkModeToggle />
        <ThemeSetting />
        <UserMenu />
      </header>
      <main class="layout-main"><RouterView /></main>
    </section>
  </div>
</template>

二、主题配置存放位置的权衡

主题配置的归属层级比具体传值方式更重要。常见的三个落点各有适用边界：

1. 放进 Menu 内部：否。主题影响头部、标签页、Logo 等多个区域，塞进单个子组件会让状态越来越乱。
2. 强耦合到全局 Store：不推荐作为第一步。基础布局组件应保持独立、可移植、低耦合，一上来就依赖某状态管理方案会降低复用性。
3. 收在 DefaultLayout：最合理的默认落点。布局内即可自洽联动，不依赖外部 Store。

正确的推进顺序是：先在 DefaultLayout 跑通本地 reactive 状态，再通过 emit 或回调把状态同步出去，最后由业务项目自行决定是否写进 Pinia 或本地持久化。Store 适合解决「跨布局、跨页面、跨刷新」的问题，而不是一开始就侵入基础组件。

三、通用抽屉容器：右侧定位加 translateX

主题设置面板天然适合抽屉而非居中模态——它不是主内容，却需较大操作空间，且可能被频繁开关。基础抽屉的核心不是结构，而是右侧固定定位配合 transform: translateX() 位移动画：

<style scoped>
.drawer-panel {
  position: fixed;
  top: 0;
  right: 0;
  width: 360px;
  height: 100%;
  transform: translateX(100%);
  transition: transform 0.3s ease;
}
.drawer-open { transform: translateX(0); }
</style>

关键设计点是把抽屉做成「可插槽的通用容器」：抽屉组件只负责结构、宽度、进出动画、标题区，具体内容通过默认插槽注入。这样既能被主题设置复用，也能承载消息面板、详情面板等后续场景，而不是写死成业务专属组件。

四、provide/inject 共享主题与图标样式

在同一布局树内部，菜单、头部、主题抽屉都处在 DefaultLayout 之下，用层层 props 传递会链路过长——provide/inject 在这里非常自然，适合「高层持有状态、深层多组件读写」的场景。真实项目更推荐用 InjectionKey 而非裸字符串，以获得类型安全：

export const themeConfigKey: InjectionKey<ThemeConfig> = Symbol("theme-config")
provide(themeConfigKey, themeConfig)

菜单图标的大小、间距这类内部共享样式也不应在每个 MenuItem、SubMenu 里重复硬写，而是收口到 Menu 根组件，通过 provide/inject 统一下发 iconProps（含 style、class）。注意对象型默认 props 必须用工厂函数返回，否则 Vue 会报 must be a function——多个实例会共享同一个对象引用。

五、路由 Meta 接入与稳定性收尾

目录型菜单若想挂上标题和图标，不能只有文件夹，还需要一个承载 meta 的同名页面组件（如 components.vue），它同时充当该级路由记录与子页面父容器。unplugin-vue-router 的 definePage() 适合给页面级路由补 meta（标题、图标、权限标记），但只对页面组件生效，且参数在构建时被提取，适合写静态元信息。

接通后常见的两个稳定性问题：

• 图标不显示：往往不是菜单数据缺 icon，而是 MenuItem/SubMenu 某一层忘了导入图标组件，先查导入链路再怀疑数据。
• 点击一个菜单另一个也被错误展开：多半是 key/index 生成冲突或递归自增时机错位。菜单树稳定性很大程度依赖唯一且稳定的 key，应回头检查 generateMenuKeys() 这类算法的唯一性，而不是只盯模板。

菜单背景色定制的长期兼容方案应围绕 CSS 变量：background-color / text-color / active-text-color 在 Element Plus 中已 deprecated，改用 --el-menu-bg-color、--el-menu-text-color、--el-menu-active-color 更稳。

六、布局层与业务层之间留出清晰边界

DefaultLayout 作为基础布局组件，应当尽量不依赖具体业务和具体状态管理方案。它的职责是「把菜单、头部、内容区、主题抽屉组织起来并自洽联动」，而不是替业务决定导航结构或用户体系。把基础布局做得越独立，它越能在不同项目里被直接复用；一旦在布局层写死业务字段或强耦合某个 Store，复用成本就会陡增。判断一条逻辑该不该进 DefaultLayout 的简单标准：它是否只服务于当前这个后台，还是对所有后台布局都成立。

常见问题

延伸阅读

• 上一篇：布局模式与菜单系统演进
• 下一篇：Header 与 AvatarMenu 封装演进
• 相关链接：主题切换与全屏控制、Vue Provide/Inject、Element Plus Menu