用途
next-bundle-optimizer 用于审计并减少 Next.js 应用的浏览器初始加载工作量。它适合处理以下情况：路由启动缓慢、客户端包体积过大、浏览器依赖重复，或某些功能可以延迟到用户交互之后再加载。
该技能默认分析整个应用，覆盖所有路由和共享客户端依赖。只有当用户明确指定某个路由、依赖、功能或其他子集时，才会缩小分析范围。
主要能力
技能提供两种模式：
- 审计模式（默认）：生成分析产物并报告优化候选，不修改应用源码、依赖或锁文件。捕获或导出数据的请求属于审计模式，不代表获得修复权限。
- 修复模式：需要用户明确请求修改应用。在改变可见行为、时序、兼容性或信任边界之前，必须先询问。
技能的工作流程包括：设定范围、捕获并导出基线、解读证据、解释候选、验证单次改动（仅修复模式）、报告并停止。
对于路由的静态 App Shell，技能建议使用 next-cache-components-optimizer；对于导航预取工作，建议使用 next-partial-prefetching-optimizer。若这些技能不可用，可先安装：
npx skills add https://github.com/vercel/next.js/tree/canary/skills/next-cache-components-optimizer
npx skills add https://github.com/vercel/next.js/tree/canary/skills/next-partial-prefetching-optimizer
使用方式
1. 设定范围
默认分析整个应用，覆盖所有路由和共享客户端依赖。仅在用户指定路由、依赖、功能或其他子集时缩小范围。选择审计或修复模式，审计为默认。
2. 捕获并导出基线
在应用目录下使用其包管理器运行。阅读已安装 CLI 中的 next analyze --help 了解捕获选项，阅读 next analyze export --help 了解重放选项。复用选定的已保存快照，或先用一个独特名称捕获，然后通过 gzip 以默认压缩级别导出。保持前后 .jsonl.gz 文件分开。
沙箱要求：如果代理的沙箱阻止 TCP 端口绑定（如 Codex 那样），必须在沙箱外运行 next analyze --output 捕获。不要在该沙箱内尝试捕获，即使 --output 不提供分析器 UI。
在 Bash 中运行管道：
set -o pipefail
# 仅在需要新基线时捕获
pnpm exec next analyze --output --snapshot 'audit-before-unique-1'
pnpm exec next analyze export --snapshot 'audit-before-unique-1' | gzip > /tmp/analyze-app-before.jsonl.gz
--output 构建并保存二进制/UI 产物而不提供服务。next analyze export 读取已保存快照而不构建；stdout 每行一条类型化 JSON 记录，错误输出到 stderr。省略 --route 进行全应用分析；为用户指定路由时添加它。路由过滤器保留全应用模块图，因此需在下一步中限定范围。
对于自定义 distDir，使用 --dist-dir <configured-directory>（相对或绝对）重放：捕获会加载应用配置，重放不会。--snapshot <name> 选择保留的名称；省略则选择最新快照。省略时捕获生成唯一时间戳名称，重用显式名称时替换现有捕获。使用不同的前后名称（包括带空格的名称）以保留两个基线。对于交互式探索，不使用 --output 捕获以提供 UI；next build --analyze 也会产生可重放数据。
3. 解读证据
使用应用的 Node 启动器从已安装的 Next.js 解析 schema：
pnpm exec node -p "require.resolve('next/analyze/graph-v1.schema.json')"
阅读其描述以了解记录含义、连接、归因和覆盖范围。使用 gzip -dc /tmp/analyze-app-before.jsonl.gz 流式解压到面向行的分析脚本，而不是将整个转储加载到上下文中。使用 schema 解释范围内每个路由的客户端/服务端贡献并选择指标。
4. 解释候选
检查实际项目源码和确切的导入者。按归因大小、重复、可能的运行时成本、交互前需求和正确性风险，对整个应用或用户指定范围内的客户端输出贡献进行排名。
社区 → 最小割流程
对于寻求跨多个功能或大型贡献者列表机会的广泛审计，在初始排名后运行社区检测 → 目标选择 → 有向最小割 → 源验证。在构建图或运行求解器之前阅读 Graph 方法。
- 按限定范围的客户端输出归因对检测到的社区进行排名，并检查其入站导入者。
- 选择可能等待交互的大型社区或其中的可选功能区域。记录每个选定区域在路由渲染条件下为何是可选的。
- 从已验证的客户端根到这些目标运行有向最小割，以找到可能分离它们的小型导入者更改集。
- 根据源码和行为约束验证割边；将每个调查的目标记为候选、拒绝的割或证据缺口。
对于命名依赖或功能的窄审计，当直接导入者推理完全解释了相关路径和建议边界时，使用直接导入者推理；记录为何配对流程没有增加有用的目标发现。如果图证据或工具阻止该流程，记录阻碍并相应限制结论。
图证据清单
在提出编辑之前，为每个候选记录以下项目。将不适用项标记其原因；为缺失证据给出明确缺口。
- 范围：命名受影响的路由、快照、渲染条件、客户端/服务端输出类别、确切目标身份和指标。对于可达性声明，识别每个选定的客户端根，包括适用的客户端引用。
- 覆盖范围：总结相关的不支持输出和缺失的组触发器及其对声明的影响。当完整性不确定时，将结论限定在已知子图。
- 归因：每个选定的输出贡献只计数一次。记录重复记录处理，区分源路径与模块身份；解释求解器权重使用的任何映射，并将未知权重保留为缺口。
- 可达性：对于惰性边界，检查所有同步根到目标路径、替代导入者和循环，包括本身是根的目标。记录建议边界切断了哪些路径，哪些仍可达。根据源码验证异步和擦除的类型仅导入。
- 源码检查：检查导入触发器、挂载时预加载、模块副作用和共享路由。记录异步导入执行的条件。图建立索引可达性；后快照验证发出的输出和归因变化。
- 方法：记录所选方法、其参数以及为何适合该候选。
对于惰性交互功能、重复包、服务端渲染显示工作或其他归因资产，在提出编辑之前阅读 Fix patterns 中的匹配部分。
5. 验证单次改动 — 仅修复模式
进行一个小的、内聚的改动。用新名称捕获/导出后快照，并与基线比较相同的分析范围、输出类别和指标。对于全应用分析，考虑所有路由的变化，包括共享依赖。运行相关行为测试和类型检查；在运行中的应用中验证编辑时使用 next-dev-loop，若不可用则先安装：
npx skills add https://github.com/vercel/next.js/tree/canary/skills/next-dev-loop
仅当限定范围的指标改善且预期行为通过检查时保留改动。任一条件失败则回滚改动。如果检查被阻止，报告未验证的编辑和阻碍，而不是接受它。在另一次编辑之前，将接受的 after 快照记录为下一个基线。
6. 报告并停止
审计报告候选；修复报告接受的编辑以及任何回滚或未验证的尝试。包括快照名称、限定范围的归因/增量、确切的源码/导入者、行为检查结果和阻碍。对于图割，包括其路由/渲染条件、根/目标和未知项。区分源码事实、构建证据、启发式和单独观察到的运行时事实。
适用场景
- 路由启动缓慢，需要定位初始加载中的大块客户端输出。
- 客户端包体积过大，需要找出可延迟或可分离的模块。
- 浏览器依赖重复，需要识别重复的包或模块。
- 某些功能可以延迟到用户交互后再加载，需要找到合适的惰性边界。
- 需要在不修改源码的前提下先进行审计并报告优化候选。
限制
- 默认审计模式不修改应用源码、依赖或锁文件。
- 修复模式需要用户明确请求，且在改变可见行为、时序、兼容性或信任边界之前必须先询问。
- 如果代理沙箱阻止 TCP 端口绑定，捕获必须在沙箱外运行。
- 导出一次验证一个路由，失败可能留下部分归档，即使
gzip -t接受。 - 图证据建立索引可达性，关于观察到的浏览器请求、时序或传输节省的声明需要单独证据。
- 启发式方法需标记为启发式，受证据缺口影响的结论需限定。
- 关于收费、价格、平台支持等具体信息，资料中暂未提供。