大规模应用中应分层使用全局与局部组件：全局仅限通用无状态基元、布局骨架及无副作用渲染封装；业务相关组件须局部注册，按模块组织并自动导入，辅以IDE工具提升可发现性，条件组件则动态注册。
大规模应用中，全局组件和局部组件不是“选哪个”，而是“怎么分层用”。核心原则是：全局只管真正通用的、跨域无状态的 UI 基元；其余一律按功能边界局部注册，再辅以工程化支持确保可发现、可维护。
明确划分职责边界
全局组件应严格限定在以下范围：
- 基础原子组件：如
BaseButton、BaseInput、Icon，不携带业务逻辑，无内部状态或仅管理纯视觉状态（如 hover） - 布局骨架组件：如
AppHeader、SidebarNav，结构稳定、全站复用、生命周期与根实例一致 - 无副作用的渲染封装：如
LazyImage、TooltipWrapper，内部只做 DOM 行为增强，不订阅 store 或发起请求
一旦组件涉及业务语义（如 UserCard、OrderList）、依赖 API、持有本地状态或需响应权限变化，就不再适合全局注册——它已属于某个功能模块的“局部契约”。
局部组件按模块组织 + 自动注册
避免手动在每个父组件里重复 components: { X } 。推荐采用“模块内聚 + 目录约定”方式：
- 每个业务模块（如
modules/invoice/）自带components/子目录，存放该模块专用组件 - 在模块入口（如
modules/invoice/index.ts）统一导出并注册局部组件，供本模块内所有子组件消费 - 利用构建工具（Vite/Vue CLI）的 glob 导入能力，自动收集模块内组件，减少样板代码
这样既保持作用域隔离，又避免散落式注册带来的维护成本。
用 Vetur / Vue Language Server 提升可发现性
局部组件多了，开发者容易“忘了有这个组件可用”。解决方法不是退回全局注册，而是强化 IDE 支持：
- 配置
vetur.config.js扫描src/modules/**/components和src/components/base，让 Vetur 提供精准补全 - 组件文件名强制 PascalCase（如
InvoiceSummary.vue），模板中使用时自动转为 kebab-case（<invoice-summary>），统一识别逻辑 - 配合 TypeScript 接口定义 props，在补全时直接显示类型提示和必填项标记
工具链补足了“局部性”带来的认知负担，让按需加载的优势不被开发体验抵消。
动态注册应对条件场景
某些组件只在特定环境或权限下才需要（如管理后台的 DebugPanel、多租户下的 TenantBanner），既不该全局加载，也不宜硬编码进业务组件：
- 用
defineAsyncComponent懒加载 + 权限守卫控制是否注册 - 通过插件机制，在路由守卫或登录后钩子中动态调用
app.component()注册，注册后才对后续组件可见 - 注册时附带唯一 scope 标识（如
tenant-debug-panel），避免命名冲突
这类组件本质是“条件性全局”，但生命周期由运行时策略控制，而非启动即载。
