按需引入指南 ​

QXS-BNS 当前的按需引入重点，不再是自动注册一堆 Vue 组件，而是先分清包边界，再决定是否用子入口拆分运行时代码。

先按模块拆依赖 ​

按需引入的第一步不是写构建配置，而是先确认当前页面到底需要哪一组能力。
把组件、工具、Hook、指令和图标分清楚，后面的依赖和打包体积才有机会控制住。

再决定导入策略 ​

当模块边界清楚以后，再选子入口按需引入还是整包接入。
这比一开始就堆插件配置更容易判断“多出来的依赖到底是谁带进来的”。

推荐策略 ​

1. 单组件页面 ​

如果页面只需要一个或两个组件，优先走子入口。

import '@qxs-bns/components/icon'
import '@qxs-bns/components/image-upload'

2. 题目编辑页 ​

题目页通常会同时使用多种题型、自定义元素和 helper，直接整包接入更简单。

import '@qxs-bns/components'
import {
  collectSubjectElements,
  validateSubjectElements,
} from '@qxs-bns/components'

3. 纯工具 / 指令页面 ​

如果页面只需要工具函数或指令，不要把组件包一起带进来。

import { Storage } from '@qxs-bns/utils'
import { vCopy } from '@qxs-bns/directives'

Components 包的拆分方式 ​

@qxs-bns/components 当前提供的子入口：

什么时候用整包接入 ​

以下场景推荐直接 import '@qxs-bns/components'：

• 一个页面里同时出现多个 qxs-* 元素
• 题目编辑页需要题型元素和 helper
• 文档站、playground 或内部平台需要快速挂完整能力

什么时候坚持子入口 ​

以下场景优先使用子入口：

• 单个业务页面只需要 qxs-icon 或 qxs-fixed-action-bar
• 上传页只需要 qxs-image-upload / qxs-file-upload
• 后台报表页只需要 qxs-data-chart
• 你希望把首屏组件运行时代码压到最小

Vite / Webpack 侧注意事项 ​

• 自定义元素要让编译器识别为 custom element，不要当 Vue 组件解析。
• 复杂值优先通过 DOM property 传入，不要手动序列化成 attribute。
• 如果你只使用子入口，就不要再在同一文件里整包引入一次。

常见误区 ​

同时写整包和子入口会更稳吗？ ​

不会。
这通常只会让入口看起来更混乱，而且容易让人误判到底哪些能力真正被使用了。

还需要 theme-chalk 吗？ ​

当前 @qxs-bns/components 走的是 Web Components + Shadow DOM / light DOM 混合方案，不再依赖旧的 theme-chalk 组件样式体系。

还需要 components-v2 吗？ ​

如果你的页面已经接入新的 @qxs-bns/components，通常不需要。
components-v2 只保留给还没有迁走的旧页面。

如果你原来主要依赖的是 components-v2 里的 AnswerContainer，现在优先迁到：

• @qxs-bns/components/answer-container
• <qxs-answer-container />

这条路径会先保住旧答题页最常用的 list / themeName / disabled / isShowCorrect / beforeChange / onSubmit / reset 合同，再逐步往新的单题组件体系收敛。

如果你只想看最小替换步骤，直接看 AnswerContainer 迁移速查。