用途：诊断或调优 Rspack 的 optimization.splitChunks，包括入口或异步边界间的重复模块、路由拉取大量未使用模块、chunk 过小过多、vendors/common chunk 变化频繁影响缓存、超大异步或初始 chunk 需要细分，以及澄清 splitChunks 是否影响运行时执行顺序。不适用于 ESM 库场景，其算法不同。
默认立场：区分仓库默认值与推荐的生产基线。Rspack 内置默认为 chunks: "async"，多数生产 Web 应用建议从 optimization: { splitChunks: { chunks: "all" } } 起步，并保留默认 cache groups，除非有具体理由替换。name 是改变图形状的分组选项，不是单纯的命名选项。不要用 splitChunks 推断 JS 执行顺序或 tree shaking。
主要能力与工作流程：先识别用户实际问题，一次只优化一个主目标，其余作为约束。从最安全的生产基线开始；审计高风险配置项，如固定 name、cacheGroups.*.name、enforce: true、禁用 default/defaultVendors、宽泛 test 配合单一全局 name、usedExports: false、过小 minSize、maxSize 配合手动全局命名等。正确理解 name：无 name 可保留不同 chunk 组合分离，相同 name 会把匹配模块合并为同一候选；固定 name: "vendors" 或 "common" 常导致页面拉取无关依赖链。优先保留 name 未设置，用 idHint 满足文件名标识，收窄 test，拆分宽泛 cache group，或用 maxSize 细分大 chunk。
内置 cache groups：default 提取至少被 2 个 chunk 共享的模块并复用已有 chunk；defaultVendors 提取 node_modules 模块并复用。自定义 cacheGroups 时不要随意用单一命名 vendor 桶替换它们。chunks: "all" 不会破坏执行顺序，Rspack 会把新 chunk 连回原 chunk group；执行顺序问题应优先排查运行时、引导或应用代码。
maxSize：在 chunk 已存在后才运行，切分确定，按路径派生键分组并在低相似度边界附近切分，适合解决“共享 chunk 太大”，而非“需要稳定 vendor 名”。usedExports: false 会导致更广泛共享和可能更大的 common chunk，但它不是 tree shaking。enforce: true 绕过 minSize、minChunks 和请求限制，仅在明确需要强制拆分时使用。
按目标建议：更好默认生产分块用 chunks: "all"；避免禁用 default/defaultVendors、在未测量问题前添加 name。避免拉取非必要模块：移除固定 name、保持 cache group 收窄、保留 chunks: "all"、每次改动后检查哪些路由依赖共享 chunk。改善缓存：name 不设置、用 idHint、保持 chunkIds: "deterministic" 等稳定策略，仅在包边界稳定时拆分。拆分大共享 chunk 可用 maxSize: 200000，并按需调 maxAsyncSize、maxInitialSize、hidePathInfo。
诊断配置：可用 stats: { chunks: true, chunkRelations: true, chunkOrigins: true, entrypoints: true, modules: false } 暴露 chunk 关系。
FAQ 要点：仍见重复模块的常见原因包括候选太小不满足 minSize、minSizeReduction、minChunks、请求预算限制，或 chunks/test/cacheGroups 未选中同一组合；微小模块重复可能是有意为之。splitChunks 不影响 JS 执行顺序，也不影响 tree shaking，但可能影响抽取 CSS 场景下的 CSS 顺序，需单独留意。
限制：本资料针对 Rspack splitChunks，不覆盖 ESM 库算法；具体价格、平台支持与安装步骤暂未提供。