本文将从第一人称实战视角，深入探讨前端构建工具的技术演进，以及我在设计 robuild 过程中的架构思考与工程实践。

引言：为什么我们需要又一个构建工具？

在开始正文之前，我想先回答一个无法回避的问题：在 Webpack、Rollup、esbuild、Vite 已经如此成熟的今天，为什么还要设计一个新的构建工具？

答案很简单：库构建与应用构建是两个本质不同的问题域。

Webpack 为复杂应用而生，Vite 为开发体验而生，esbuild 为速度而生。但当我们需要构建一个 npm 库时，我们需要的是：

1. 零配置：库作者不应该花时间在配置上
2. 多格式输出：ESM、CJS、甚至 UMD 一键生成
3. 类型声明：TypeScript 项目的 .d.ts 自动生成
4. Tree-shaking 友好：输出代码必须对消费者友好
5. 极致性能：构建速度不应该成为开发瓶颈

robuild 就是为解决这些问题而设计的。它基于 Rolldown（Rust 实现的 Rollup 替代品）和 Oxc（Rust 实现的 JavaScript 工具链），专注于库构建场景。

接下来，让我从构建工具的历史演进说起。

---

第一章：构建工具的三次演进

1.1 第一次革命：Webpack 时代（2012-2017）

2012 年，Webpack 横空出世，彻底改变了前端工程化的格局。

在 Webpack 之前，前端工程师面对的是一个碎片化的世界：RequireJS 处理模块加载，Grunt/Gulp 处理任务流程，各种工具各司其职却又互不兼容。Webpack 的革命性在于它提出了一个统一的心智模型：一切皆模块。

// Webpack 的核心思想：统一的依赖图
// JS、CSS、图片、字体，都是图中的节点
module.exports = {
  entry: './src/index.js',
  module: {
    rules: [
      { test: /\.css$/, use: ['style-loader', 'css-loader'] },
      { test: /\.png$/, use: ['file-loader'] }
    ]
  }
}

Webpack 的架构基于以下核心概念：

1. 依赖图（Dependency Graph）：从入口点出发，递归解析所有依赖
2. Loader 机制：将非 JS 资源转换为模块
3. Plugin 系统：基于 Tapable 的事件驱动架构
4. Chunk 分割：智能的代码分割策略

但 Webpack 也有其历史局限性：

• 配置复杂：动辄数百行的配置文件
• 构建速度：随着项目规模增长，构建时间呈指数级增长
• 输出冗余：运行时代码占比较高，不利于库构建

1.2 第二次革命：Rollup 时代（2017-2022）

2017 年左右，Rollup 开始崛起，它代表了一种完全不同的设计哲学：面向 ES Module 的静态分析。

Rollup 的核心创新是 Tree Shaking——通过静态分析 ES Module 的 import/export 语句，只打包实际使用的代码。这在库构建场景下意义重大：

// input.js
import { add, multiply } from './math.js'
console.log(add(2, 3))
// multiply 未使用

// math.js
export function add(a, b) { return a + b }
export function multiply(a, b) { return a * b }

// output.js (Rollup 输出，multiply 被移除)
function add(a, b) { return a + b }
console.log(add(2, 3))

Rollup 能做到这一点，是因为 ES Module 具有以下静态特性：

1. 静态导入：import 语句必须在模块顶层，不能动态
2. 静态导出：export 的绑定在编译时就能确定
3. 只读绑定：导入的值不能被重新赋值

这使得编译器可以在构建时进行精确的依赖分析，而不需要运行代码。

作用域提升（Scope Hoisting） 是 Rollup 的另一个重要特性。与 Webpack 将每个模块包裹在函数中不同，Rollup 会将所有模块"展平"到同一个作用域：

// Webpack 风格的输出
var __webpack_modules__ = {
  "./src/a.js": (module) => { module.exports = 1 },
  "./src/b.js": (module, exports, require) => {
    const a = require("./src/a.js")
    module.exports = a + 1
  }
}

// Rollup 风格的输出
const a = 1
const b = a + 1

这种输出更紧凑、运行时开销更低，非常适合库构建。

1.3 第三次革命：Rust Bundler 时代（2022-今）

2022 年开始，我们迎来了构建工具的第三次革命：Rust 重写一切。

这场革命的先驱是 esbuild（Go 语言）和 SWC（Rust）。它们用系统级语言重写了 JavaScript 的解析、转换、打包流程，获得了 10-100 倍的性能提升。

为什么 Rust 成为了这场革命的主角？

1. 零成本抽象：高级语言特性不带来运行时开销
2. 内存安全：编译器保证没有数据竞争和悬空指针
3. 真正的并行：无 GC 停顿，能充分利用多核
4. 可编译到 WASM：可以在浏览器和 Node.js 中运行

Rolldown 和 Oxc 是这场革命的最新成果：

Rolldown：Rollup 的 Rust 实现，由 Vue.js 团队主导，目标是成为 Vite 的默认打包器。它保持了 Rollup 的 API 兼容性，同时获得了 Rust 带来的性能优势。

Oxc：一个完整的 JavaScript 工具链，包括解析器、转换器、代码检查器、格式化器、压缩器。它的设计目标是成为 Babel、ESLint、Prettier、Terser 的统一替代品。

传统工具链                    Oxc 工具链
Babel (转换)                 oxc-transform
ESLint (检查)        →       oxc-linter
Prettier (格式化)            oxc-formatter
Terser (压缩)                oxc-minify

robuild 选择基于 Rolldown + Oxc 构建，正是看中了这两个项目的技术潜力和生态定位。

---

第二章：理解 Bundler 核心原理

在深入 robuild 的设计之前，我想先从原理层面解释 Bundler 是如何工作的。我会实现一个 Mini Bundler，让你真正理解打包器的核心逻辑。

2.1 从零实现 Mini Bundler

一个最简的 Bundler 需要完成以下步骤：

1. 解析：将源代码转换为 AST
2. 依赖收集：从 AST 中提取 import 语句
3. 依赖图构建：递归处理所有依赖，构建完整的模块图
4. 打包：将所有模块合并为单个文件

下面是完整的实现代码：

// mini-bundler.js
// 一个完整的 Mini Bundler 实现，约 300 行代码
// 支持 ES Module 解析、依赖图构建、打包输出

import * as fs from 'node:fs'
import * as path from 'node:path'
import { parse } from '@babel/parser'
import traverse from '@babel/traverse'
import { transformFromAstSync } from '@babel/core'

// ============================================
// 第一部分：模块解析器
// ============================================

let moduleId = 0  // 模块计数器，用于生成唯一 ID

/**
 * 解析单个模块
 * @param {string} filePath - 模块文件的绝对路径
 * @returns {Object} 模块信息对象
 */
function parseModule(filePath) {
  const content = fs.readFileSync(filePath, 'utf-8')

  // 1. 使用 Babel 解析为 AST
  // 这里我们支持 TypeScript 和 JSX
  const ast = parse(content, {
    sourceType: 'module',
    plugins: ['typescript', 'jsx']
  })

  // 2. 收集依赖信息
  const dependencies = []
  const imports = []  // 详细的导入信息
  const exports = []  // 详细的导出信息

  traverse.default(ast, {
    // 处理 import 声明
    // import { foo, bar } from './module'
    // import defaultExport from './module'
    // import * as namespace from './module'
    ImportDeclaration({ node }) {
      const specifier = node.source.value
      dependencies.push(specifier)

      // 提取导入的具体内容
      const importedNames = node.specifiers.map(spec => {
        if (spec.type === 'ImportDefaultSpecifier') {
          return { type: 'default', local: spec.local.name }
        }
        if (spec.type === 'ImportNamespaceSpecifier') {
          return { type: 'namespace', local: spec.local.name }
        }
        // ImportSpecifier
        return {
          type: 'named',
          imported: spec.imported.name,
          local: spec.local.name
        }
      })

      imports.push({
        specifier,
        importedNames,
        start: node.start,
        end: node.end
      })
    },

    // 处理动态 import()
    // const mod = await import('./module')
    CallExpression({ node }) {
      if (node.callee.type === 'Import' &&
          node.arguments[0]?.type === 'StringLiteral') {
        dependencies.push(node.arguments[0].value)
        imports.push({
          specifier: node.arguments[0].value,
          isDynamic: true,
          start: node.start,
          end: node.end
        })
      }
    },

    // 处理 export 声明
    // export { foo, bar }
    // export const x = 1
    // export default function() {}
    ExportNamedDeclaration({ node }) {
      if (node.declaration) {
        // export const x = 1
        if (node.declaration.declarations) {
          for (const decl of node.declaration.declarations) {
            exports.push({
              type: 'named',
              name: decl.id.name,
              local: decl.id.name
            })
          }
        }
        // export function foo() {}
        else if (node.declaration.id) {
          exports.push({
            type: 'named',
            name: node.declaration.id.name,
            local: node.declaration.id.name
          })
        }
      }
      // export { foo, bar }
      for (const spec of node.specifiers || []) {
        exports.push({
          type: 'named',
          name: spec.exported.name,
          local: spec.local.name
        })
      }
      // export { foo } from './module'
      if (node.source) {
        dependencies.push(node.source.value)
      }
    },

    ExportDefaultDeclaration({ node }) {
      exports.push({ type: 'default', name: 'default' })
    },

    // export * from './module'
    ExportAllDeclaration({ node }) {
      dependencies.push(node.source.value)
      exports.push({
        type: 'star',
        from: node.source.value,
        as: node.exported?.name  // export * as name
      })
    }
  })

  // 3. 转换代码：移除类型注解，转换为 CommonJS
  // 这样我们可以在运行时执行
  const { code } = transformFromAstSync(ast, content, {
    presets: ['@babel/preset-typescript'],
    plugins: [
      ['@babel/plugin-transform-modules-commonjs', {
        strict: true,
        noInterop: false
      }]
    ]
  })

  return {
    id: moduleId++,
    filePath,
    dependencies,
    imports,
    exports,
    code,
    ast
  }
}

// ============================================
// 第二部分：模块路径解析
// ============================================

/**
 * 解析模块路径
 * 将 import 语句中的相对路径转换为绝对路径
 */
function resolveModule(specifier, fromDir) {
  // 相对路径
  if (specifier.startsWith('.') || specifier.startsWith('/')) {
    let resolved = path.resolve(fromDir, specifier)

    // 尝试添加扩展名
    const extensions = ['.ts', '.tsx', '.js', '.jsx', '.mjs', '.json']

    // 直接匹配文件
    for (const ext of extensions) {
      const withExt = resolved + ext
      if (fs.existsSync(withExt)) {
        return withExt
      }
    }

    // 尝试 index 文件
    for (const ext of extensions) {
      const indexPath = path.join(resolved, `index${ext}`)
      if (fs.existsSync(indexPath)) {
        return indexPath
      }
    }

    // 如果原路径存在（有扩展名的情况）
    if (fs.existsSync(resolved)) {
      return resolved
    }

    throw new Error(`Cannot resolve module: ${specifier} from ${fromDir}`)
  }

  // 外部模块（node_modules）
  // 简化处理，返回原始标识符
  return specifier
}

/**
 * 判断是否为外部模块
 */
function isExternalModule(specifier) {
  return !specifier.startsWith('.') && !specifier.startsWith('/')
}

// ============================================
// 第三部分：依赖图构建
// ============================================

/**
 * 构建依赖图
 * 从入口开始，递归解析所有模块
 * @param {string} entryPath - 入口文件路径
 * @returns {Array} 模块数组（拓扑排序）
 */
function buildDependencyGraph(entryPath) {
  const absoluteEntry = path.resolve(entryPath)
  const entryModule = parseModule(absoluteEntry)

  // 广度优先遍历
  const moduleQueue = [entryModule]
  const moduleMap = new Map()  // filePath -> module
  moduleMap.set(absoluteEntry, entryModule)

  for (const module of moduleQueue) {
    const dirname = path.dirname(module.filePath)

    // 存储依赖映射：相对路径 -> 模块 ID
    module.mapping = {}

    for (const dep of module.dependencies) {
      // 跳过外部模块
      if (isExternalModule(dep)) {
        module.mapping[dep] = null  // null 表示外部依赖
        continue
      }

      // 解析依赖的绝对路径
      const depPath = resolveModule(dep, dirname)

      // 避免重复解析
      if (moduleMap.has(depPath)) {
        module.mapping[dep] = moduleMap.get(depPath).id
        continue
      }

      // 解析新的依赖模块
      const depModule = parseModule(depPath)
      moduleMap.set(depPath, depModule)
      moduleQueue.push(depModule)
      module.mapping[dep] = depModule.id
    }
  }

  // 返回模块数组
  return Array.from(moduleMap.values())
}

// ============================================
// 第四部分：代码生成
// ============================================

/**
 * 生成打包后的代码
 * @param {Array} modules - 模块数组
 * @returns {string} 打包后的代码
 */
function generateBundle(modules) {
  // 生成模块定义
  let modulesCode = ''

  for (const mod of modules) {
    // 每个模块包装为 [factory, mapping] 格式
    // factory 是模块工厂函数
    // mapping 是依赖映射表
    modulesCode += `
    // ${mod.filePath}
    ${mod.id}: [
      function(module, exports, require) {
        ${mod.code}
      },
      ${JSON.stringify(mod.mapping)}
    ],`
  }

  // 生成运行时代码
  const runtime = `
// Mini Bundler 输出
// 生成时间: ${new Date().toISOString()}

(function(modules) {
  // 模块缓存
  const cache = {}

  // 自定义 require 函数
  function require(id) {
    // 如果是外部模块（id 为 null），使用原生 require
    if (id === null) {
      throw new Error('External module should be loaded via native require')
    }

    // 检查缓存
    if (cache[id]) {
      return cache[id].exports
    }

    // 获取模块定义
    const [factory, mapping] = modules[id]

    // 创建模块对象
    const module = {
      exports: {}
    }

    // 缓存模块（处理循环依赖）
    cache[id] = module

    // 创建本地 require 函数
    // 将相对路径映射为模块 ID
    function localRequire(name) {
      const mappedId = mapping[name]

      // 外部模块
      if (mappedId === null) {
        // 在实际环境中，这里应该使用 native require
        // 为了演示，我们抛出错误
        if (typeof window === 'undefined') {
          return require(name)  // Node.js 环境
        }
        throw new Error(\`External module not available: \${name}\`)
      }

      return require(mappedId)
    }

    // 执行模块工厂函数
    factory(module, module.exports, localRequire)

    return module.exports
  }

  // 执行入口模块（ID 为 0）
  require(0)

})({${modulesCode}
})
`

  return runtime
}

// ============================================
// 第五部分：主入口
// ============================================

/**
 * 打包入口
 * @param {string} entryPath - 入口文件路径
 * @param {string} outputPath - 输出文件路径
 */
function bundle(entryPath, outputPath) {
  console.log(`\n📦 Mini Bundler`)
  console.log(`   Entry: ${entryPath}`)
  console.log(`   Output: ${outputPath}\n`)

  // 1. 构建依赖图
  console.log('1. Building dependency graph...')
  const modules = buildDependencyGraph(entryPath)
  console.log(`   Found ${modules.length} modules:`)
  for (const mod of modules) {
    console.log(`   - [${mod.id}] ${path.relative(process.cwd(), mod.filePath)}`)
    console.log(`         Deps: ${mod.dependencies.join(', ') || '(none)'}`)
  }

  // 2. 生成打包代码
  console.log('\n2. Generating bundle...')
  const bundledCode = generateBundle(modules)

  // 3. 写入文件
  const outputDir = path.dirname(outputPath)
  if (!fs.existsSync(outputDir)) {
    fs.mkdirSync(outputDir, { recursive: true })
  }
  fs.writeFileSync(outputPath, bundledCode, 'utf-8')

  // 4. 输出统计
  const stats = fs.statSync(outputPath)
  console.log(`\n3. Bundle stats:`)
  console.log(`   Size: ${(stats.size / 1024).toFixed(2)} KB`)
  console.log(`   Modules: ${modules.length}`)

  console.log(`\n✅ Bundle created successfully!`)
  console.log(`   ${outputPath}\n`)

  return { modules, code: bundledCode }
}

// 导出 API
export {
  bundle,
  parseModule,
  buildDependencyGraph,
  generateBundle,
  resolveModule
}

// CLI 支持
if (process.argv[2]) {
  const entry = process.argv[2]
  const output = process.argv[3] || './dist/bundle.js'
  bundle(entry, output)
}

让我们用一个例子测试这个 Mini Bundler：

// src/index.js - 入口文件
import { add, multiply } from './math.js'
import { formatResult } from './utils/format.js'

const result = add(2, 3)
console.log(formatResult('2 + 3', result))
console.log(formatResult('2 * 3', multiply(2, 3)))

// src/math.js - 数学工具
export function add(a, b) {
  return a + b
}

export function multiply(a, b) {
  return a * b
}

export function subtract(a, b) {
  return a - b
}

// src/utils/format.js - 格式化工具
export function formatResult(expression, result) {
  return `${expression} = ${result}`
}

运行打包：

node mini-bundler.js src/index.js dist/bundle.js

输出：

📦 Mini Bundler
   Entry: src/index.js
   Output: dist/bundle.js

1. Building dependency graph...
   Found 3 modules:
   - [0] src/index.js
         Deps: ./math.js, ./utils/format.js
   - [1] src/math.js
         Deps: (none)
   - [2] src/utils/format.js
         Deps: (none)

2. Generating bundle...

3. Bundle stats:
   Size: 1.84 KB
   Modules: 3

✅ Bundle created successfully!
   dist/bundle.js

2.2 AST 依赖分析深入

上面的代码使用 Babel 进行解析。让我们更深入地看看 AST 依赖分析的细节。

ES Module 的依赖信息主要来自以下 AST 节点类型：

// 1. ImportDeclaration - 静态导入
import defaultExport from './module.js'
import { named } from './module.js'
import * as namespace from './module.js'

// 2. ExportNamedDeclaration - 具名导出（可能包含 re-export）
export { foo } from './module.js'
export { default as foo } from './module.js'

// 3. ExportAllDeclaration - 星号导出
export * from './module.js'
export * as name from './module.js'

// 4. ImportExpression - 动态导入
const mod = await import('./module.js')

下面是一个更完整的依赖提取实现：

/**
 * 从 AST 中提取所有依赖信息
 * 返回结构化的依赖对象
 */
function extractDependencies(ast, filePath) {
  const result = {
    // 静态导入
    staticImports: [],
    // 动态导入
    dynamicImports: [],
    // Re-export
    reExports: [],
    // CommonJS require（用于分析混合代码）
    requires: [],
    // 导出信息
    exports: {
      named: [],      // export { foo }
      default: false, // export default
      star: []        // export * from
    }
  }

  traverse.default(ast, {
    // ===== 导入 =====

    ImportDeclaration({ node }) {
      const specifier = node.source.value

      // 提取导入的具体绑定
      const bindings = node.specifiers.map(spec => {
        switch (spec.type) {
          case 'ImportDefaultSpecifier':
            return {
              type: 'default',
              local: spec.local.name,
              imported: 'default'
            }
          case 'ImportNamespaceSpecifier':
            return {
              type: 'namespace',
              local: spec.local.name,
              imported: '*'
            }
          case 'ImportSpecifier':
            return {
              type: 'named',
              local: spec.local.name,
              imported: spec.imported.name
            }
        }
      })

      result.staticImports.push({
        specifier,
        bindings,
        // 位置信息用于 source map 和错误报告
        loc: {
          start: node.loc.start,
          end: node.loc.end
        }
      })
    },

    // 动态 import()
    ImportExpression({ node }) {
      const source = node.source

      if (source.type === 'StringLiteral') {
        // 静态字符串
        result.dynamicImports.push({
          specifier: source.value,
          isDynamic: false,
          loc: node.loc
        })
      } else {
        // 动态表达式，无法静态分析
        result.dynamicImports.push({
          specifier: null,
          isDynamic: true,
          expression: source,
          loc: node.loc
        })
      }
    },

    // ===== 导出 =====

    ExportNamedDeclaration({ node }) {
      // export { foo, bar as baz }
      for (const spec of node.specifiers || []) {
        result.exports.named.push({
          exported: spec.exported.name,
          local: spec.local.name
        })
      }

      // export const x = 1 / export function foo() {}
      if (node.declaration) {
        const decl = node.declaration
        if (decl.declarations) {
          // VariableDeclaration
          for (const d of decl.declarations) {
            result.exports.named.push({
              exported: d.id.name,
              local: d.id.name
            })
          }
        } else if (decl.id) {
          // FunctionDeclaration / ClassDeclaration
          result.exports.named.push({
            exported: decl.id.name,
            local: decl.id.name
          })
        }
      }

      // export { foo } from './module'
      if (node.source) {
        result.reExports.push({
          specifier: node.source.value,
          bindings: node.specifiers.map(spec => ({
            exported: spec.exported.name,
            imported: spec.local.name
          })),
          loc: node.loc
        })
      }
    },

    ExportDefaultDeclaration({ node }) {
      result.exports.default = true
    },

    ExportAllDeclaration({ node }) {
      result.exports.star.push({
        specifier: node.source.value,
        as: node.exported?.name || null
      })

      result.reExports.push({
        specifier: node.source.value,
        bindings: '*',
        as: node.exported?.name,
        loc: node.loc
      })
    },

    // ===== CommonJS =====

    CallExpression({ node }) {
      // require('module')
      if (node.callee.type === 'Identifier' &&
          node.callee.name === 'require' &&
          node.arguments[0]?.type === 'StringLiteral') {
        result.requires.push({
          specifier: node.arguments[0].value,
          loc: node.loc
        })
      }
    }
  })

  return result
}

2.3 Tree Shaking 简化实现

Tree Shaking 的核心是标记-清除算法：

1. 标记阶段：从入口点开始，标记所有"活"的导出
2. 清除阶段：移除所有未标记的代码

下面是一个简化的 Tree Shaking 实现：

/**
 * 简化的 Tree Shaking 实现
 * 核心思想：追踪哪些导出被使用了
 */
class TreeShaker {
  constructor() {
    this.modules = new Map()       // moduleId -> ModuleInfo
    this.usedExports = new Map()   // moduleId -> Set<exportName>
    this.sideEffectModules = new Set()
  }

  /**
   * 添加模块到分析器
   */
  addModule(moduleInfo) {
    this.modules.set(moduleInfo.id, moduleInfo)

    // 分析模块导出
    moduleInfo.exportMap = new Map()

    for (const exp of moduleInfo.exports) {
      if (exp.type === 'named' || exp.type === 'default') {
        moduleInfo.exportMap.set(exp.name, {
          type: exp.type,
          local: exp.local,
          // 追踪导出来源（本地声明 or re-export）
          source: exp.from || null
        })
      }
    }

    // 检测副作用
    moduleInfo.hasSideEffects = this.detectSideEffects(moduleInfo)
  }

  /**
   * 检测模块是否有副作用
   * 副作用包括：顶层函数调用、全局变量修改等
   */
  detectSideEffects(moduleInfo) {
    const { ast } = moduleInfo

    let hasSideEffects = false

    traverse.default(ast, {
      // 顶层表达式语句可能有副作用
      ExpressionStatement(path) {
        // 只检查顶层
        if (path.parent.type === 'Program') {
          const expr = path.node.expression

          // 函数调用
          if (expr.type === 'CallExpression') {
            hasSideEffects = true
          }

          // 赋值表达式
          if (expr.type === 'AssignmentExpression') {
            // 检查是否是全局变量赋值
            const left = expr.left
            if (left.type === 'Identifier') {
              // 简化判断：非 const/let/var 声明的赋值
              hasSideEffects = true
            }
            if (left.type === 'MemberExpression') {
              // window.foo = ... / global.bar = ...
              hasSideEffects = true
            }
          }
        }
      }
    })

    return hasSideEffects
  }

  /**
   * 从入口开始标记使用的导出
   */
  markFromEntry(entryId) {
    const entryModule = this.modules.get(entryId)

    // 入口模块的所有导出都被认为"使用"
    const allExports = Array.from(entryModule.exportMap.keys())
    this.markUsed(entryId, allExports)
  }

  /**
   * 标记模块的导出为已使用
   */
  markUsed(moduleId, exportNames) {
    // 初始化集合
    if (!this.usedExports.has(moduleId)) {
      this.usedExports.set(moduleId, new Set())
    }

    const used = this.usedExports.get(moduleId)
    const module = this.modules.get(moduleId)

    for (const name of exportNames) {
      if (used.has(name)) continue  // 已处理
      used.add(name)

      // 查找导出定义
      const exportInfo = module.exportMap.get(name)
      if (!exportInfo) continue

      // 如果是 re-export，递归标记源模块
      if (exportInfo.source) {
        const sourceModule = this.findModuleBySpecifier(module, exportInfo.source)
        if (sourceModule) {
          this.markUsed(sourceModule.id, [exportInfo.local])
        }
      }

      // 追踪本地导出引用的导入
      this.traceImports(module, exportInfo.local)
    }

    // 如果模块有副作用，标记为必须包含
    if (module.hasSideEffects) {
      this.sideEffectModules.add(moduleId)
    }
  }

  /**
   * 追踪导出绑定使用的导入
   */
  traceImports(module, localName) {
    // 简化实现：标记该模块所有导入的模块
    // 完整实现需要进行作用域分析

    for (const imp of module.imports || []) {
      // 检查导入的绑定是否被使用
      for (const binding of imp.bindings || []) {
        if (binding.local === localName) {
          const sourceModule = this.findModuleBySpecifier(module, imp.specifier)
          if (sourceModule) {
            // 标记使用的具体导出
            const usedExport = binding.imported === 'default'
              ? 'default'
              : binding.imported
            this.markUsed(sourceModule.id, [usedExport])
          }
        }
      }
    }
  }

  /**
   * 根据模块说明符查找模块
   */
  findModuleBySpecifier(fromModule, specifier) {
    const targetId = fromModule.mapping?.[specifier]
    if (targetId !== undefined && targetId !== null) {
      return this.modules.get(targetId)
    }
    return null
  }

  /**
   * 获取 Shake 后的结果
   */
  getShakeResult() {
    const includedModules = []
    const excludedExports = new Map()

    for (const [moduleId, module] of this.modules) {
      const used = this.usedExports.get(moduleId) || new Set()
      const hasSideEffects = this.sideEffectModules.has(moduleId)

      // 包含条件：有使用的导出 OR 有副作用
      if (used.size > 0 || hasSideEffects) {
        includedModules.push({
          id: moduleId,
          path: module.filePath,
          usedExports: Array.from(used),
          hasSideEffects
        })

        // 记录未使用的导出
        const allExports = Array.from(module.exportMap.keys())
        const unused = allExports.filter(e => !used.has(e))
        if (unused.length > 0) {
          excludedExports.set(moduleId, unused)
        }
      }
    }

    return {
      includedModules,
      excludedExports,
      stats: {
        totalModules: this.modules.size,
        includedModules: includedModules.length,
        removedModules: this.modules.size - includedModules.length
      }
    }
  }
}

// 使用示例
function performTreeShaking(modules, entryId) {
  const shaker = new TreeShaker()

  // 添加所有模块
  for (const mod of modules) {
    shaker.addModule(mod)
  }

  // 从入口开始标记
  shaker.markFromEntry(entryId)

  // 获取结果
  return shaker.getShakeResult()
}

2.4 作用域分析核心思路

作用域分析是 Tree Shaking 和变量重命名的基础。核心挑战是正确处理 JavaScript 的作用域规则：

/**
 * 作用域分析器
 * 构建作用域树，追踪变量的声明和引用
 */
class ScopeAnalyzer {
  constructor() {
    this.scopes = []
    this.currentScope = null
  }

  /**
   * 分析 AST，构建作用域树
   */
  analyze(ast) {
    // 创建全局/模块作用域
    this.currentScope = this.createScope('module', null)

    traverse.default(ast, {
      // ===== 作用域边界 =====

      // 函数创建新作用域
      FunctionDeclaration: (path) => {
        this.enterFunctionScope(path)
      },
      'FunctionDeclaration:exit': () => {
        this.exitScope()
      },

      FunctionExpression: (path) => {
        this.enterFunctionScope(path)
      },
      'FunctionExpression:exit': () => {
        this.exitScope()
      },

      ArrowFunctionExpression: (path) => {
        this.enterFunctionScope(path)
      },
      'ArrowFunctionExpression:exit': () => {
        this.exitScope()
      },

      // 块级作用域（if、for、while 等）
      BlockStatement: (path) => {
        // 只有包含 let/const 声明时才创建块级作用域
        if (this.hasBlockScopedDeclarations(path.node)) {
          this.enterBlockScope(path)
        }
      },
      'BlockStatement:exit': (path) => {
        if (this.hasBlockScopedDeclarations(path.node)) {
          this.exitScope()
        }
      },

      // ===== 声明 =====

      VariableDeclaration: (path) => {
        const kind = path.node.kind  // var, let, const

        for (const decl of path.node.declarations) {
          this.declareBinding(decl.id, kind, path)
        }
      },

      FunctionDeclaration: (path) => {
        if (path.node.id) {
          // 函数声明提升到外层作用域
          this.declareBinding(path.node.id, 'function', path)
        }
      },

      ClassDeclaration: (path) => {
        if (path.node.id) {
          this.declareBinding(path.node.id, 'class', path)
        }
      },

      ImportDeclaration: (path) => {
        for (const spec of path.node.specifiers) {
          this.declareBinding(spec.local, 'import', path)
        }
      },

      // ===== 引用 =====

      Identifier: (path) => {
        if (this.isReference(path)) {
          this.recordReference(path.node.name, path)
        }
      }
    })

    return this.scopes
  }

  /**
   * 创建新作用域
   */
  createScope(type, parent) {
    const scope = {
      id: this.scopes.length,
      type,           // 'module', 'function', 'block'
      parent,
      children: [],
      bindings: new Map(),    // name -> BindingInfo
      references: [],         // 引用列表
      // 统计信息
      stats: {
        declarations: 0,
        references: 0
      }
    }

    if (parent) {
      parent.children.push(scope)
    }

    this.scopes.push(scope)
    return scope
  }

  /**
   * 进入函数作用域
   */
  enterFunctionScope(path) {
    const scope = this.createScope('function', this.currentScope)
    this.currentScope = scope

    // 函数参数作为绑定
    for (const param of path.node.params || []) {
      this.declarePattern(param, 'param')
    }
  }

  /**
   * 进入块级作用域
   */
  enterBlockScope(path) {
    const scope = this.createScope('block', this.currentScope)
    this.currentScope = scope
  }

  /**
   * 退出当前作用域
   */
  exitScope() {
    this.currentScope = this.currentScope.parent
  }

  /**
   * 声明绑定
   */
  declareBinding(id, kind, path) {
    const name = id.name

    // var 声明提升到函数作用域
    const targetScope = kind === 'var'
      ? this.findFunctionScope()
      : this.currentScope

    // 创建绑定信息
    const binding = {
      name,
      kind,           // 'var', 'let', 'const', 'function', 'class', 'param', 'import'
      node: id,
      path,
      scope: targetScope,
      references: [],
      isExported: false,
      isUsed: false
    }

    targetScope.bindings.set(name, binding)
    targetScope.stats.declarations++

    return binding
  }

  /**
   * 处理解构模式
   */
  declarePattern(pattern, kind) {
    switch (pattern.type) {
      case 'Identifier':
        this.declareBinding(pattern, kind, null)
        break

      case 'ObjectPattern':
        for (const prop of pattern.properties) {
          if (prop.type === 'RestElement') {
            this.declarePattern(prop.argument, kind)
          } else {
            this.declarePattern(prop.value, kind)
          }
        }
        break

      case 'ArrayPattern':
        for (const element of pattern.elements) {
          if (element) {
            if (element.type === 'RestElement') {
              this.declarePattern(element.argument, kind)
            } else {
              this.declarePattern(element, kind)
            }
          }
        }
        break

      case 'AssignmentPattern':
        this.declarePattern(pattern.left, kind)
        break

      case 'RestElement':
        this.declarePattern(pattern.argument, kind)
        break
    }
  }

  /**
   * 记录变量引用
   */
  recordReference(name, path) {
    // 从当前作用域向上查找绑定
    let scope = this.currentScope

    while (scope) {
      const binding = scope.bindings.get(name)
      if (binding) {
        binding.references.push(path)
        binding.isUsed = true
        scope.stats.references++
        return
      }
      scope = scope.parent
    }

    // 未找到绑定，是全局变量引用
    this.currentScope.references.push({
      name,
      path,
      isGlobal: true
    })
  }

  /**
   * 判断 Identifier 是否为引用（而非声明）
   */
  isReference(path) {
    const parent = path.parent
    const node = path.node

    // 声明的左侧
    if (parent.type === 'VariableDeclarator' && parent.id === node) {
      return false
    }

    // 函数声明名称
    if (parent.type === 'FunctionDeclaration' && parent.id === node) {
      return false
    }

    // 类声明名称
    if (parent.type === 'ClassDeclaration' && parent.id === node) {
      return false
    }

    // 对象属性键（非计算属性）
    if (parent.type === 'Property' && parent.key === node && !parent.computed) {
      return false
    }

    // 对象方法名
    if (parent.type === 'MethodDefinition' && parent.key === node && !parent.computed) {
      return false
    }

    // 成员访问的属性（非计算）
    if (parent.type === 'MemberExpression' && parent.property === node && !parent.computed) {
      return false
    }

    // import 语句中的导入名
    if (parent.type === 'ImportSpecifier' && parent.imported === node) {
      return false
    }

    // export 语句中的导出名
    if (parent.type === 'ExportSpecifier' && parent.exported === node) {
      return false
    }

    return true
  }

  /**
   * 查找最近的函数作用域
   */
  findFunctionScope() {
    let scope = this.currentScope
    while (scope && scope.type === 'block') {
      scope = scope.parent
    }
    return scope || this.currentScope
  }

  /**
   * 检查块是否包含块级作用域声明
   */
  hasBlockScopedDeclarations(block) {
    for (const stmt of block.body) {
      if (stmt.type === 'VariableDeclaration' &&
          (stmt.kind === 'let' || stmt.kind === 'const')) {
        return true
      }
    }
    return false
  }

  /**
   * 获取未使用的绑定
   */
  getUnusedBindings() {
    const unused = []

    for (const scope of this.scopes) {
      for (const [name, binding] of scope.bindings) {
        if (!binding.isUsed && !binding.isExported) {
          unused.push({
            name,
            kind: binding.kind,
            scope: scope.type,
            loc: binding.node?.loc
          })
        }
      }
    }

    return unused
  }
}

---

第三章：robuild 完整架构设计

了解了 Bundler 的基本原理后，让我们深入 robuild 的架构设计。

3.1 核心设计原则

robuild 的设计遵循以下原则：

1. 零配置优先：默认配置应该覆盖 90% 的使用场景
2. 渐进式复杂度：简单任务简单做，复杂任务可配置
3. 兼容性：支持 tsup 和 unbuild 的配置风格
4. 性能：利用 Rust 工具链的性能优势
5. 可扩展：插件系统支持自定义逻辑

3.2 架构总览

┌──────────────────────────────────────────────────────────────────┐
│                          CLI Layer                                │
│  ┌─────────────────────────────────────────────────────────────┐ │
│  │  cac（命令行解析）→ c12（配置加载）→ build()              │ │
│  └─────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘
                                ↓
┌──────────────────────────────────────────────────────────────────┐
│                        Config Layer                               │
│  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐  │
│  │ normalizeTsup   │  │ inheritConfig   │  │ resolveExternal │  │
│  │ Config()       │→│      ()          │→│    Config()     │  │
│  └─────────────────┘  └─────────────────┘  └─────────────────┘  │
└──────────────────────────────────────────────────────────────────┘
                                ↓
┌──────────────────────────────────────────────────────────────────┐
│                        Build Layer                                │
│  ┌─────────────────────────────┐  ┌─────────────────────────┐   │
│  │     rolldownBuild()         │  │    transformDir()       │   │
│  │  ┌─────────────────────┐    │  │  ┌─────────────────┐    │   │
│  │  │ Rolldown + DTS Plugin│   │  │  │ Oxc Transform   │    │   │
│  │  └─────────────────────┘    │  │  └─────────────────┘    │   │
│  └─────────────────────────────┘  └─────────────────────────┘   │
└──────────────────────────────────────────────────────────────────┘
                                ↓
┌──────────────────────────────────────────────────────────────────┐
│                       Plugin Layer                                │
│  ┌───────────┐  ┌───────────┐  ┌───────────┐  ┌───────────┐    │
│  │  Shims    │  │  Shebang  │  │  Node     │  │  Glob     │    │
│  │  Plugin   │  │  Plugin   │  │  Protocol │  │  Import   │    │
│  └───────────┘  └───────────┘  └───────────┘  └───────────┘    │
└──────────────────────────────────────────────────────────────────┘
                                ↓
┌──────────────────────────────────────────────────────────────────┐
│                      Transform Layer                              │
│  ┌───────────┐  ┌───────────┐  ┌───────────┐  ┌───────────┐    │
│  │  Banner   │  │  Clean    │  │  Copy     │  │  Exports  │    │
│  │  Footer   │  │  Output   │  │  Files    │  │  Generate │    │
│  └───────────┘  └───────────┘  └───────────┘  └───────────┘    │
└──────────────────────────────────────────────────────────────────┘

3.3 构建流程详解

robuild 的构建流程分为以下阶段：

                    build() 入口
                         │
          ┌──────────────┴──────────────┐
          ↓                             ↓
   normalizeTsupConfig()         performWatchBuild()
   (标准化配置格式)                  (Watch 模式)
          │
          ↓
   inheritConfig()
   (配置继承)
          │
          ↓
   ┌──────┴──────┐
   │   entries   │
   │   遍历      │
   └──────┬──────┘
          │
   ┌──────┴──────┬──────────────┐
   ↓             ↓              ↓
 Bundle       Transform      其他类型
 Entry        Entry          ...
   │             │
   ↓             ↓
rolldownBuild  transformDir
   │             │
   └──────┬──────┘
          ↓
   generateExports()
   (生成 package.json exports)
          │
          ↓
   executeOnSuccess()
   (执行回调)

让我们深入关键环节：

3.3.1 配置标准化

robuild 支持两种配置风格：

// tsup 风格（flat config）
export default {
  entry: ['./src/index.ts'],
  format: ['esm', 'cjs'],
  dts: true
}

// unbuild 风格（entries-based）
export default {
  entries: [
    { type: 'bundle', input: './src/index.ts', format: ['esm', 'cjs'] },
    { type: 'transform', input: './src/' }
  ]
}

配置标准化的核心代码：

// src/build.ts
function normalizeTsupConfig(config: BuildConfig): BuildConfig {
  // 如果已经有 entries，直接返回
  if (config.entries && config.entries.length > 0) {
    return config
  }

  // 将 tsup 风格的 entry 转换为 entries
  if (config.entry) {
    const entry: BundleEntry = inheritConfig(
      {
        type: 'bundle' as const,
        entry: config.entry,
      },
      config,
      { name: 'globalName' } // 字段映射
    )
    return { ...config, entries: [entry] }
  }

  return config
}

3.3.2 配置继承

顶层配置需要向下传递给每个 entry：

const SHARED_CONFIG_FIELDS = [
  'format', 'outDir', 'platform', 'target', 'minify',
  'dts', 'splitting', 'treeshake', 'sourcemap',
  'external', 'noExternal', 'env', 'alias', 'banner',
  'footer', 'shims', 'rolldown', 'loaders', 'clean'
] as const

function inheritConfig<T extends Partial<BuildEntry>>(
  entry: T,
  config: BuildConfig,
  additionalMappings?: Record<string, string>
): T {
  const result: any = { ...entry }

  // 只继承未定义的字段
  for (const field of SHARED_CONFIG_FIELDS) {
    if (result[field] === undefined && config[field] !== undefined) {
      result[field] = config[field]
    }
  }

  // 处理字段映射（如 name -> globalName）
  if (additionalMappings) {
    for (const [configKey, entryKey] of Object.entries(additionalMappings)) {
      if (result[entryKey] === undefined) {
        result[entryKey] = (config as any)[configKey]
      }
    }
  }

  return result
}

3.3.3 并行构建

所有 entries 并行构建，提升性能：

await Promise.all(
  entries.map(entry =>
    entry.type === 'bundle'
      ? rolldownBuild(ctx, entry, hooks, config)
      : transformDir(ctx, entry)
  )
)

3.4 Bundle Builder 实现

Bundle Builder 是 robuild 的核心，它封装了 Rolldown 的调用：

// src/builders/bundle.ts
export async function rolldownBuild(
  ctx: BuildContext,
  entry: BundleEntry,
  hooks: BuildHooks,
  config?: BuildConfig
): Promise<void> {
  // 1. 初始化插件管理器
  const pluginManager = new RobuildPluginManager(config || {}, entry, ctx.pkgDir)
  await pluginManager.initializeRobuildHooks()

  // 2. 解析配置
  const formats = Array.isArray(entry.format) ? entry.format : [entry.format || 'es']
  const platform = entry.platform || 'node'
  const target = entry.target || 'es2022'

  // 3. 清理输出目录
  await cleanOutputDir(ctx.pkgDir, fullOutDir, entry.clean ?? true)

  // 4. 处理外部依赖
  const externalConfig = resolveExternalConfig(ctx, {
    external: entry.external,
    noExternal: entry.noExternal
  })

  // 5. 构建插件列表
  const rolldownPlugins: Plugin[] = [
    shebangPlugin(),
    nodeProtocolPlugin(entry.nodeProtocol || false),
    // ... 其他插件
  ]

  // 6. 构建 Rolldown 配置
  const baseRolldownConfig: InputOptions = {
    cwd: ctx.pkgDir,
    input: inputs,
    plugins: rolldownPlugins,
    platform: platform === 'node' ? 'node' : 'neutral',
    external: externalConfig,
    resolve: { alias: entry.alias || {} },
    transform: { target, define: defineOptions }
  }

  // 7. 所有格式并行构建
  const formatResults = await Promise.all(formats.map(buildFormat))

  // 8. 执行构建结束钩子
  await pluginManager.executeRobuildBuildEnd({ allOutputEntries })
}

关键设计点：

多格式构建：ESM、CJS、IIFE 等格式同时构建，通过不同的文件扩展名避免冲突：

const buildFormat = async (format: ModuleFormat) => {
  let entryFileName = `[name]${extension}`

  if (isMultiFormat) {
    // 多格式构建时使用明确的扩展名
    if (format === 'cjs') entryFileName = `[name].cjs`
    else if (format === 'esm') entryFileName = `[name].mjs`
    else if (format === 'iife') entryFileName = `[name].js`
  }

  const res = await rolldown(formatConfig)
  await res.write(outConfig)
  await res.close()
}

DTS 生成策略：只在 ESM 格式下生成类型声明，避免冲突：

if (entry.dts !== false && format === 'esm') {
  formatConfig.plugins = [
    ...plugins,
    dts({ cwd: ctx.pkgDir, ...entry.dts })
  ]
}

3.5 Transform Builder 实现

Transform Builder 用于不打包的场景，保持目录结构：

// src/builders/transform.ts
export async function transformDir(
  ctx: BuildContext,
  entry: TransformEntry
): Promise<void> {
  // 获取所有源文件
  const files = await glob('**/*.*', { cwd: inputDir })

  const promises = files.map(async (entryName) => {
    const ext = extname(entryPath)

    switch (ext) {
      case '.ts':
      case '.tsx':
      case '.jsx': {
        // 使用 Oxc 转换
        const transformed = await transformModule(entryPath, entry)
        await writeFile(entryDistPath, transformed.code, 'utf8')

        // 生成类型声明
        if (transformed.declaration) {
          await writeFile(dtsPath, transformed.declaration, 'utf8')
        }
        break
      }
      default:
        // 其他文件直接复制
        await copyFile(entryPath, entryDistPath)
    }
  })

  await Promise.all(promises)
}

单文件转换使用 Oxc：

async function transformModule(entryPath: string, entry: TransformEntry) {
  const sourceText = await readFile(entryPath, 'utf8')

  // 1. 解析 AST
  const parsed = parseSync(entryPath, sourceText, {
    lang: ext === '.tsx' ? 'tsx' : 'ts',
    sourceType: 'module'
  })

  // 2. 重写相对导入（使用 MagicString 保持 sourcemap 兼容）
  const magicString = new MagicString(sourceText)
  for (const staticImport of parsed.module.staticImports) {
    // 将 .ts 导入重写为 .mjs
    rewriteSpecifier(staticImport.moduleRequest)
  }

  // 3. Oxc 转换
  const transformed = await transform(entryPath, magicString.toString(), {
    target: entry.target || 'es2022',
    sourcemap: !!entry.sourcemap,
    typescript: {
      declaration: { stripInternal: true }
    }
  })

  // 4. 可选压缩
  if (entry.minify) {
    const res = await minify(entryPath, transformed.code, entry.minify)
    transformed.code = res.code
  }

  return transformed
}

---

第四章：ESM/CJS 互操作处理

ESM 和 CJS 的互操作是库构建中最复杂的问题之一。让我详细解释 robuild 是如何处理的。

4.1 问题背景

ESM 和 CJS 有根本性的差异：

特性	ESM	CJS
加载时机	静态（编译时）	动态（运行时）
导出方式	具名绑定	module.exports 对象
this 值	undefined	module
__dirname	不可用	可用
require	不可用	可用
顶层 await	支持	不支持

4.2 Shims 插件设计

robuild 通过 Shims 插件解决兼容问题：

// ESM 中使用 CJS 特性时的 shim
const NODE_GLOBALS_SHIM = `
// Node.js globals shim for ESM
import { fileURLToPath } from 'node:url'
import { dirname } from 'node:path'
import { createRequire } from 'node:module'

const __filename = fileURLToPath(import.meta.url)
const __dirname = dirname(__filename)
const require = createRequire(import.meta.url)
`

// 浏览器环境的 process.env shim
const PROCESS_ENV_SHIM = `
if (typeof process === 'undefined') {
  globalThis.process = {
    env: {},
    platform: 'browser',
    version: '0.0.0'
  }
}
`

// module.exports shim
const MODULE_EXPORTS_SHIM = `
if (typeof module === 'undefined') {
  globalThis.module = { exports: {} }
}
if (typeof exports === 'undefined') {
  globalThis.exports = module.exports
}
`

关键是检测需要哪些 shim：

function detectShimNeeds(code: string) {
  // 移除注释和字符串，避免误判
  const cleanCode = removeCommentsAndStrings(code)

  return {
    needsDirname: /\b__dirname\b/.test(cleanCode) ||
                  /\b__filename\b/.test(cleanCode),
    needsRequire: /\brequire\s*\(/.test(cleanCode),
    needsExports: /\bmodule\.exports\b/.test(cleanCode) ||
                  /\bexports\.\w+/.test(cleanCode),
    needsEnv: /\bprocess\.env\b/.test(cleanCode)
  }
}

function removeCommentsAndStrings(code: string): string {
  return code
    // 移除单行注释
    .replace(/\/\/.*$/gm, '')
    // 移除多行注释
    .replace(/\/\*[\s\S]*?\*\//g, '')
    // 移除字符串字面量
    .replace(/"(?:[^"\\]|\\.)*"/g, '""')
    .replace(/'(?:[^'\\]|\\.)*'/g, "''")
    .replace(/`(?:[^`\\]|\\.)*`/g, '``')
}

4.3 平台特定配置

不同平台需要不同的 shim 策略：

function getPlatformShimsConfig(platform: 'browser' | 'node' | 'neutral') {
  switch (platform) {
    case 'browser':
      return {
        dirname: false,  // 浏览器不支持
        require: false,  // 浏览器不支持
        exports: false,  // 浏览器不支持
        env: true        // 需要 polyfill
      }
    case 'node':
      return {
        dirname: true,   // 转换为 ESM 等价写法
        require: true,   // 使用 createRequire
        exports: true,   // 转换为 ESM export
        env: false       // 原生支持
      }
    case 'neutral':
      return {
        dirname: false,
        require: false,
        exports: false,
        env: false
      }
  }
}

4.4 Dual Package 支持

对于同时支持 ESM 和 CJS 的包，robuild 自动生成正确的 exports 字段：

// 输入配置
{
  entries: [{
    type: 'bundle',
    input: './src/index.ts',
    format: ['esm', 'cjs'],
    generateExports: true
  }]
}

// 生成的 package.json exports
{
  "exports": {
    ".": {
      "types": "./dist/index.d.mts",  // TypeScript 优先
      "import": "./dist/index.mjs",    // ESM
      "require": "./dist/index.cjs"    // CJS
    }
  }
}

顺序很重要：types 必须在最前面，这是 TypeScript 的要求。

---

第五章：插件系统设计哲学

5.1 设计目标

robuild 的插件系统需要满足：

1. 兼容性：支持 Rolldown、Rollup、Vite、Unplugin 插件
2. 简洁性：简单需求不需要复杂配置
3. 可组合：多个插件可以组合成一个
4. 生命周期明确：robuild 特有的钩子

5.2 插件类型检测

robuild 自动识别插件类型：

class RobuildPluginManager {
  private normalizePlugin(pluginOption: RobuildPluginOption): RobuildPlugin {
    // 工厂函数
    if (typeof pluginOption === 'function') {
      return this.normalizePlugin(pluginOption())
    }

    // 类型检测优先级
    if (this.isRobuildPlugin(pluginOption)) return pluginOption
    if (this.isRolldownPlugin(pluginOption)) return this.adaptRolldownPlugin(pluginOption)
    if (this.isVitePlugin(pluginOption)) return this.adaptVitePlugin(pluginOption)
    if (this.isUnplugin(pluginOption)) return this.adaptUnplugin(pluginOption)

    // 兜底：当作 Rolldown 插件
    return this.adaptRolldownPlugin(pluginOption)
  }

  // Robuild 插件：有 robuild 特有钩子或标记
  private isRobuildPlugin(plugin: any): plugin is RobuildPlugin {
    return plugin.meta?.robuild === true
      || plugin.robuildSetup
      || plugin.robuildBuildStart
      || plugin.robuildBuildEnd
  }

  // Rolldown/Rollup 插件：有标准钩子
  private isRolldownPlugin(plugin: any): plugin is RolldownPlugin {
    return plugin.name && (
      plugin.buildStart || plugin.buildEnd ||
      plugin.resolveId || plugin.load || plugin.transform ||
      plugin.generateBundle || plugin.writeBundle
    )
  }

  // Vite 插件：有 Vite 特有钩子
  private isVitePlugin(plugin: any): boolean {
    return plugin.config || plugin.configResolved ||
           plugin.configureServer || plugin.meta?.vite === true
  }
}

5.3 Robuild 特有钩子

除了 Rolldown 标准钩子，robuild 添加了三个生命周期钩子：

interface RobuildPlugin extends RolldownPlugin {
  // 插件初始化时调用
  robuildSetup?: (ctx: RobuildPluginContext) => void | Promise<void>

  // 构建开始时调用
  robuildBuildStart?: (ctx: RobuildPluginContext) => void | Promise<void>

  // 构建结束时调用，可以访问所有输出
  robuildBuildEnd?: (ctx: RobuildPluginContext, result?: any) => void | Promise<void>
}

interface RobuildPluginContext {
  config: BuildConfig
  entry: BuildEntry
  pkgDir: string
  outDir: string
  format: ModuleFormat | ModuleFormat[]
  platform: Platform
  target: Target
}

5.4 插件工厂模式

robuild 提供工厂函数简化插件创建：

// 创建简单的 transform 插件
function createTransformPlugin(
  name: string,
  transform: (code: string, id: string) => string | null,
  filter?: (id: string) => boolean
): RobuildPlugin {
  return {
    name,
    meta: { robuild: true },
    transform: async (code, id) => {
      if (filter && !filter(id)) return null
      return transform(code, id)
    }
  }
}

// 使用示例
const myPlugin = createTransformPlugin(
  'add-banner',
  (code) => `/* My Library */\n${code}`,
  (id) => /\.js$/.test(id)
)

组合多个插件：

function combinePlugins(name: string, plugins: RobuildPlugin[]): RobuildPlugin {
  const combined: RobuildPlugin = { name, meta: { robuild: true } }

  for (const plugin of plugins) {
    // 链式组合 transform 钩子
    if (plugin.transform) {
      const prevHook = combined.transform
      combined.transform = async (code, id) => {
        let currentCode = code
        if (prevHook) {
          const result = await prevHook(currentCode, id)
          if (result) {
            currentCode = typeof result === 'string' ? result : result.code
          }
        }
        return plugin.transform!(currentCode, id)
      }
    }

    // 其他钩子类似处理...
  }

  return combined
}

---

第六章：性能优化策略

6.1 为什么 Rust 更快？

robuild 使用的 Rolldown 和 Oxc 都是 Rust 实现的。Rust 带来的性能优势主要来自：

1. 零成本抽象

Rust 的泛型和 trait 在编译时单态化，没有运行时开销：

// Rust: 编译时展开，没有虚函数调用
fn process<T: Transform>(input: T) -> String {
    input.transform()
}

// 等价于为每个具体类型生成特化版本
fn process_for_type_a(input: TypeA) -> String { ... }
fn process_for_type_b(input: TypeB) -> String { ... }

2. 无 GC 暂停

JavaScript 的垃圾回收会导致不可预测的暂停。Rust 通过所有权系统在编译时确定内存释放时机：

// Rust: 编译器自动插入内存释放
{
    let ast = parse(source);  // 分配内存
    let result = transform(ast);
    // ast 在这里自动释放，无需 GC
}

3. 数据局部性

Rust 鼓励使用栈分配和连续内存，对 CPU 缓存更友好：

// 连续内存布局
struct Token {
    kind: TokenKind,
    start: u32,
    end: u32,
}
let tokens: Vec<Token> = tokenize(source);
// tokens 在连续内存中，缓存命中率高

4. 真正的并行

Rust 的类型系统保证线程安全，可以放心使用多核：

use rayon::prelude::*;

// 多个文件并行解析
let results: Vec<_> = files
    .par_iter()  // 并行迭代
    .map(|file| parse(file))
    .collect();

6.2 robuild 的并行策略

robuild 在多个层面实现并行：

Entry 级并行：所有 entry 同时构建

await Promise.all(
  entries.map(entry =>
    entry.type === 'bundle'
      ? rolldownBuild(ctx, entry, hooks, config)
      : transformDir(ctx, entry)
  )
)

Format 级并行：ESM、CJS 等格式同时生成

const formatResults = await Promise.all(formats.map(buildFormat))

文件级并行：Transform 模式下所有文件同时处理

const writtenFiles = await Promise.all(promises)

6.3 缓存策略

robuild 在应用层做了一些优化：

依赖缓存：解析结果缓存

// 依赖解析缓存
const depsCache = new Map<OutputChunk, Set<string>>()
const resolveDeps = (chunk: OutputChunk): string[] => {
  if (!depsCache.has(chunk)) {
    depsCache.set(chunk, new Set<string>())
  }
  const deps = depsCache.get(chunk)!
  // ... 递归解析
  return Array.from(deps).sort()
}

外部模块判断缓存：避免重复的包信息读取

// 一次性构建外部依赖列表
const externalDeps = buildExternalDeps(ctx.pkg)
// 后续直接查表判断

---

第七章：为什么选择 Rust + JS 混合架构

7.1 架构选择的权衡

robuild 采用 Rust + JavaScript 混合架构。这个选择背后有深思熟虑的权衡：

为什么不是纯 Rust？

1. 生态兼容性：npm 生态的插件都是 JavaScript，纯 Rust 无法复用
2. 配置灵活性：JavaScript 配置文件可以动态计算、条件判断
3. 开发效率：Rust 开发周期长，不利于快速迭代
4. 用户学习成本：用户不需要学习 Rust 就能写插件

为什么不是纯 JavaScript？

1. 性能瓶颈：AST 解析、转换、压缩都是 CPU 密集型任务
2. 内存效率：大型项目的 AST 占用大量内存
3. 并行能力：JavaScript 单线程无法利用多核

最佳策略：计算密集型用 Rust，胶水层用 JavaScript

┌─────────────────────────────────────────────────────────────┐
│                    JavaScript 层                             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │  配置加载、CLI、插件管理、构建编排、输出处理          │  │
│  └───────────────────────────────────────────────────────┘  │
│                           │                                  │
│                      NAPI 绑定                               │
│                           │                                  │
│  ┌───────────────────────────────────────────────────────┐  │
│  │              Rust 层（计算密集型）                     │  │
│  │  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐     │  │
│  │  │ Parser  │ │Transform│ │ Bundler │ │ Minifier│     │  │
│  │  │ (Oxc)   │ │ (Oxc)   │ │(Rolldown)│ │ (Oxc)  │     │  │
│  │  └─────────┘ └─────────┘ └─────────┘ └─────────┘     │  │
│  └───────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘

7.2 NAPI 绑定的成本

Rust 和 JavaScript 之间通过 NAPI（Node-API）通信。这有一定开销：

1. 数据序列化：JavaScript 对象转换为 Rust 结构
2. 跨边界调用：每次调用有固定开销
3. 字符串复制：UTF-8 字符串需要复制

因此，robuild 的设计原则是减少跨边界调用次数：

// 好的做法：一次调用完成整个解析
const parsed = parseSync(filePath, sourceText, options)

// 不好的做法：多次调用
const ast = parse(source)
const imports = extractImports(ast)  // 又一次跨边界
const exports = extractExports(ast)  // 又一次跨边界

7.3 与 Vite 生态的协同

robuild 的架构设计与 Vite 生态高度契合：

1. Rolldown 是 Vite 的未来打包器：API 兼容 Rollup，便于迁移
2. 插件复用：Vite 插件可以直接在 robuild 中使用
3. 配置兼容：支持从 vite.config.ts 导入配置

// robuild 可以加载 Vite 配置
export default {
  fromVite: true,  // 启用 Vite 配置加载
  // robuild 特有配置可以覆盖
  entries: [...]
}

---

第八章：实战案例与最佳实践

8.1 最简配置

对于标准的 TypeScript 库，零配置即可工作：

// build.config.ts
export default {}

// 等价于
export default {
  entries: [{
    type: 'bundle',
    input: './src/index.ts',
    format: ['esm'],
    dts: true
  }]
}

8.2 多入口 + 多格式

// build.config.ts
export default {
  entries: [
    {
      type: 'bundle',
      input: {
        index: './src/index.ts',
        cli: './src/cli.ts'
      },
      format: ['esm', 'cjs'],
      dts: true,
      generateExports: true
    }
  ],
  exports: {
    enabled: true,
    autoUpdate: true
  }
}

8.3 带 shims 的 Node.js 工具

// build.config.ts
export default {
  entries: [{
    type: 'bundle',
    input: './src/index.ts',
    format: ['esm'],
    platform: 'node',
    shims: {
      dirname: true,   // __dirname, __filename
      require: true    // require()
    },
    banner: '#!/usr/bin/env node'
  }]
}

8.4 浏览器库 + UMD

// build.config.ts
export default {
  entries: [{
    type: 'bundle',
    input: './src/index.ts',
    format: ['esm', 'umd'],
    platform: 'browser',
    globalName: 'MyLib',
    minify: true,
    shims: {
      env: true  // process.env polyfill
    }
  }]
}

8.5 Monorepo 内部包

// build.config.ts
export default {
  entries: [{
    type: 'bundle',
    input: './src/index.ts',
    format: ['esm'],
    dts: true,
    noExternal: [
      '@myorg/utils',     // 打包内部依赖
      '@myorg/shared'
    ]
  }]
}

---

结语：构建工具的未来

回顾构建工具的三次革命：

1. Webpack 时代：解决了"如何打包复杂应用"
2. Rollup 时代：解决了"如何打包高质量的库"
3. Rust Bundler 时代：解决了"如何更快地完成这一切"

robuild 是这场革命的参与者。它基于 Rolldown + Oxc 的 Rust 基础设施，专注于库构建场景，追求零配置、高性能、与现有生态兼容。

但构建工具的演进远未结束。我们可以期待：

1. 更深的编译器集成：bundler 与类型检查器、代码检查器的融合
2. 更智能的优化：基于运行时 profile 的优化决策
3. 更好的开发体验：更快的 HMR、更精准的错误提示
4. WebAssembly 的普及：让 Rust 工具链在浏览器中运行

构建工具的本质是将开发者的代码高效地转换为运行时需要的形态。技术在变，这个目标不变。作为工具开发者，我们的使命是让这个过程尽可能无感、高效、可靠。

感谢阅读。如果你对 robuild 感兴趣，欢迎查看 项目仓库。

---

本文约 10000 字，涵盖了构建工具演进、bundler 核心原理（含完整 mini bundler 代码）、robuild 架构设计、ESM/CJS 互操作、插件系统、性能优化等主题。如有技术问题，欢迎讨论交流。

参考资料：

• Rolldown 官方文档
• Oxc 官方文档
• Rollup 插件开发指南
• robuild 源码

【Unity Shader Graph 使用与特效实现】专栏-直达

Shadow Mask 节点是 Unity URP Shader Graph 中一个重要的光照处理节点，专门用于获取烘焙后的 ShadowMask 信息。在实时渲染和烘焙光照结合的场景中，Shadow Mask 技术发挥着关键作用，它允许开发者在保持高性能的同时实现高质量的阴影效果。通过将静态阴影信息预计算并存储在纹理中，Shadow Mask 节点能够在运行时高效地应用这些预计算数据，为场景提供逼真的阴影交互。

Shadow Mask 节点的核心功能是输出一个包含四个灯光 shadowmask 信息的数据结构，每个通道分别对应不同灯光的阴影遮蔽数据。这种四通道的输出结构使得开发者能够同时处理多个光源的阴影信息，为复杂光照场景的渲染提供了便利。在 URP 渲染管线中，Shadow Mask 节点是实现高质量静态阴影的关键工具，特别适合需要平衡性能与视觉效果的项目。

描述

Shadow Mask 节点的主要作用是获取场景中烘焙后的 ShadowMask 信息。在 Unity 的光照烘焙系统中，静态物体的阴影信息可以被预计算并存储在特定的纹理中，这些纹理就是 ShadowMask。Shadow Mask 节点允许着色器在运行时访问这些预计算的阴影数据，从而实现高效的阴影渲染。

Shadow Mask 技术的核心优势在于其性能优化能力。通过将耗实的实时阴影计算转换为纹理采样操作，显著降低了 GPU 的计算负担。这对于移动设备或性能受限的平台尤为重要。Shadow Mask 节点输出的数据结构包含四个灯光的 shadowmask 信息，每个通道（R、G、B、A）分别对应一个特定灯光的阴影遮蔽数据。这种设计使得单个节点能够处理多个光源的阴影信息，提高了着色器的效率。

在实际应用中，Shadow Mask 节点通常与光照贴图（Lightmap）系统配合使用。当场景中的静态物体被标记为参与光照烘焙时，Unity 会生成包含阴影信息的 ShadowMask 纹理。Shader Graph 中的 Shadow Mask 节点通过采样这些纹理，为材质提供准确的阴影数据。这种机制确保了静态物体能够呈现出与动态物体相协调的阴影效果，同时保持渲染性能。

Shadow Mask 节点的一个重要特性是其输出的阴影数据是经过预计算的，这意味着阴影的质量和精度在烘焙阶段就已经确定。因此，在使用 Shadow Mask 节点时，开发者需要确保光照烘焙的质量设置能够满足项目的视觉需求。高质量的烘焙设置会产生更精确的阴影边缘和更自然的阴影过渡，而低质量的设置可能会导致阴影出现锯齿或模糊。

支持的渲染管线

• 通用渲染管线（Universal Render Pipeline）

高清渲染管线（High Definition Render Pipeline）不支持此节点。这是因为不同的渲染管线采用了不同的阴影处理架构和光照系统。URP 作为轻量级的渲染管线，其 Shadow Mask 实现更加注重性能和移动设备的兼容性，而 HDRP 则使用了更复杂的阴影系统，如屏幕空间阴影和光线追踪阴影，因此不需要传统的 Shadow Mask 节点。

URP 中的 Shadow Mask 节点是专门为该渲染管线的光照系统设计的，它与 URP 的光照烘焙流程紧密集成。开发者在使用此节点时，需要确保项目使用的是 URP 模板，并且光照设置正确配置了 ShadowMask 模式。如果项目从内置渲染管线或其他渲染管线迁移而来，可能需要重新配置光照设置才能正确使用 Shadow Mask 节点。

端口

Shadow Mask 节点包含两个主要端口：一个输入端口和一个输出端口。这些端口定义了节点与其他着色器节点的数据流，理解每个端口的功能对于正确使用 Shadow Mask 节点至关重要。

名称	方向	类型	绑定	描述
Lightmap UV	输入	Vector 2	无	输入光照贴图的 UV 坐标
Out	输出	Vector 4	无	输出包含四个灯光的 shadowmask 信息（RGBA 通道）

Lightmap UV 输入端口

Lightmap UV 输入端口接收 Vector 2 类型的数据，表示光照贴图的 UV 坐标。这些坐标用于在 ShadowMask 纹理中进行采样，以获取对应位置的阴影信息。光照贴图 UV 通常由网格的第二个 UV 通道提供，这个通道专门用于光照贴图和 ShadowMask 的映射。

在使用 Lightmap UV 输入端口时，开发者需要注意以下几点：

• UV 坐标必须正确对应到光照贴图的空间。如果 UV 坐标不正确，可能会导致阴影采样位置错误，出现阴影错位或缺失的问题。
• 对于动态生成的或程序化创建的网格，需要确保其包含有效的第二套 UV 坐标，否则 Shadow Mask 节点将无法正常工作。
• 在某些情况下，开发者可能需要使用 UV 变换节点对光照贴图 UV 进行调整，以解决 UV 拉伸或扭曲问题。

Lightmap UV 输入端口的典型连接方式是从顶点着色器获取第二套 UV 坐标，或者使用特定的 UV 节点生成。在 Shader Graph 中，可以通过 Position 节点或 Sample Texture 2D 节点的 UV 输出来获取光照贴图 UV。

Out 输出端口

Out 输出端口产生 Vector 4 类型的数据，包含四个通道的 shadowmask 信息。每个通道对应一个特定灯光的阴影遮蔽数据：

• R 通道：通常对应场景中的第一个重要灯光的阴影信息
• G 通道：对应第二个重要灯光的阴影信息
• B 通道：对应第三个重要灯光的阴影信息
• A 通道：对应第四个重要灯光的阴影信息

输出的 shadowmask 数据表示对应位置受到各光源阴影影响的程度。数值为 1 表示完全不受阴影影响（完全照亮），数值为 0 表示完全处于阴影中，中间值则表示部分阴影状态。

在实际使用中，开发者需要了解场景中灯光的重要性排序，以正确解释各通道对应的光源。Unity 通常会根据灯光的强度和距离等因素自动确定灯光的重要性顺序。如果需要精确控制，可以在光照设置中进行调整。

注意事项

• 输出的数据结构包含四个灯光的 shadowmask，每个通道分别表示不同灯光的阴影信息（R、G、B、A 通道）。这意味着单个 Shadow Mask 节点最多可以处理四个光源的阴影数据。如果场景中包含超过四个光源，额外的光源可能不会包含在 ShadowMask 中，或者需要使用其他技术处理。
• 适用于光照烘焙后的场景，结合此节点的输出可有效优化阴影计算和渲染性能。Shadow Mask 节点依赖于正确完成的光照烘焙过程。在使用此节点前，需要确保场景已经进行了适当的光照烘焙，并且静态物体正确标记了参与 ShadowMask 生成。
• Shadow Mask 节点只处理静态阴影信息，对于动态物体的阴影，仍然需要实时阴影技术。这意味着在同一个场景中，可能需要结合使用 Shadow Mask 和实时阴影来实现完整的阴影效果。
• Shadow Mask 的质量直接受光照烘焙设置的影响。低质量的烘焙设置可能导致阴影边缘锯齿或精度不足，而高质量的设置则会产生更自然的阴影过渡。
• 在移动设备上使用 Shadow Mask 节点时，需要注意纹理采样次数和内存占用。过多的 ShadowMask 纹理可能会影响性能，因此需要合理规划场景的光照复杂度。

Shadow Mask 节点的实际应用

Shadow Mask 节点在游戏开发中有多种应用场景，理解这些应用场景有助于开发者更好地利用这一技术。

静态场景阴影渲染

在大型开放世界或复杂室内场景中，静态物体的阴影可以通过 Shadow Mask 节点高效渲染。与实时阴影相比，这种方法显著降低了性能开销，同时保持了高质量的阴影效果。通过将静态阴影预计算并存储在纹理中，GPU 只需进行简单的纹理采样操作，而不需要执行复杂的阴影计算。

在实际实现中，开发者可以将 Shadow Mask 节点的输出与主纹理颜色相乘，从而将阴影效果应用到材质上。这种技术特别适合地面、墙壁和其他静态环境元素的阴影渲染。

混合光照场景

在混合光照场景中，既有烘焙的静态光照，也有实时的动态光照，Shadow Mask 节点可以帮助统一这两种光照系统的阴影表现。通过将烘焙阴影与实时阴影结合，可以创建出既高效又视觉丰富的照明环境。

例如，在一个室内场景中，来自窗户的自然光可以通过光照烘焙处理为静态阴影，而角色手中的手电筒则可以产生实时阴影。Shadow Mask 节点负责处理静态阴影部分，而实时阴影则通过其他技术实现，两者结合创造出连贯的视觉体验。

性能优化

对于性能敏感的平台如移动设备或VR应用，Shadow Mask 节点是优化阴影渲染的重要工具。通过将昂贵的实时阴影计算转换为廉价的纹理采样，可以显著提高渲染性能，同时保持可接受的视觉质量。

在优化过程中，开发者需要注意 ShadowMask 纹理的分辨率和压缩设置。过高的分辨率会增加内存占用和带宽使用，而过低的分辨率则可能导致阴影质量下降。需要根据目标平台的性能和视觉要求找到合适的平衡点。

Shadow Mask 节点的配置与最佳实践

要充分发挥 Shadow Mask 节点的潜力，开发者需要了解其配置方法和最佳实践。

光照设置配置

在使用 Shadow Mask 节点前，需要在 Unity 的光照窗口中正确配置 ShadowMask 模式：

• 打开光照窗口（Window > Rendering > Lighting）
• 在光照设置中，找到 Shadowmask 模式选项
• 选择 Shadowmask 模式而非 Distance Shadowmask 或其他模式
• 设置合适的 Shadowmask 分辨率和其他烘焙参数

正确的光照设置是 Shadow Mask 节点正常工作的前提。如果设置不正确，可能会导致 ShadowMask 纹理无法生成或生成质量不佳。

材质和着色器配置

在 Shader Graph 中使用 Shadow Mask 节点时，需要确保材质的相关属性正确设置：

• 确保材质使用了支持光照贴图的着色器
• 检查材质的渲染队列和混合模式是否与 ShadowMask 技术兼容
• 对于透明或半透明材质，可能需要特殊的处理方式来正确混合阴影

性能考量

在使用 Shadow Mask 节点时，需要考虑以下性能因素：

• ShadowMask 纹理的内存占用：高分辨率的 ShadowMask 纹理会占用更多内存，需要根据目标平台的能力进行权衡
• 纹理采样开销：每个使用 Shadow Mask 节点的材质都会增加纹理采样操作，在性能受限的平台上需要控制使用数量
• 烘焙时间：高质量的 ShadowMask 烘焙需要较长的计算时间，在开发过程中需要平衡烘焙质量与迭代速度

调试和问题排查

当 Shadow Mask 节点不按预期工作时，可以采取以下调试步骤：

• 检查光照烘焙是否成功完成，查看控制台是否有相关错误或警告
• 使用帧调试器（Frame Debugger）检查 ShadowMask 纹理是否正确绑定和采样
• 验证网格的第二套 UV 坐标是否正确生成，没有重叠或扭曲
• 检查光照设置中的 Shadowmask 模式是否正确配置

通过系统性的调试，可以快速定位并解决 Shadow Mask 节点相关的问题，确保阴影效果正确呈现。

---

【Unity Shader Graph 使用与特效实现】专栏-直达 （欢迎点赞留言探讨，更多人加入进来能更加完善这个探索的过程，🙏）

据猫眼专业版数据，2026年春节档观影人次破亿，春节档已连续8年观影人次破亿。

据外媒报道，在美国最高法院裁决后，印度新德里官员透露，印度贸易官员将推迟前往美国的行程，此前计划敲定印美达成的临时贸易协议。会谈将重新安排在较晚的日期。印度本月早些时候与美国达成了一个临时框架，特朗普将印度商品的税率从25%降至18%，并取消了额外的25%惩罚性关税。印度官员们表示，此次访问将在两国研究和评估事态发展及其影响后进行。（新浪财经）

从中国国家铁路集团有限公司获悉，2月21日春运过半，全国铁路当日发送旅客1718.7万人次，累计发送旅客2.58亿人次，运输安全平稳有序。2月22日正月初六，全国铁路客流持续高位运行，预计发送旅客1793万人次，计划加开旅客列车2203列。（新华社）

完整错误信息：Text components are not supported for now in ReactKonva. You text is: "xxxxx"

这个问题常出现的主要原因是，我在konva得组件里注入非konva的组件。

错误示例：

import {Stage,Layer,React,Circle} from "react-konva"

<Stage width={window.innerWidth } height={window.innerHeight}>
  <Layer>
     <div>
        <Rect/>
        <Circle/>
     </div>
  </Layer>
</Stage>

其中，div就是非konva的组件。

把div去掉就好啦

据HuggingFace官网最新数据显示，截至2月22日，Boss直聘南北阁实验室最新开源模型Nanbeige4.1-3B已进入全球模型总趋势榜前三，并位列文本模型趋势榜第一。公开资料显示，Nanbeige4.1-3B 仅具备 30 亿参数规模，却在通用问答、复杂推理、代码生成与深度搜索等多项核心任务中展现出突出的跨任务泛化能力与综合能力表现。

据美国方面2月21日消息，在美国总统特朗普宣布将新一轮全球关税提高至15%后，美国洛杉矶港负责人表示，美国企业面临更大的不确定性。洛杉矶港执行董事吉恩·塞罗卡表示，在政策走向不明的情况下，企业难以进行人才、投资和技术方面的长期战略规划。他预计，未来美国经济将面临一段“颠簸之路”，消费者可能会感受到价格上涨带来的压力。（央视新闻）

来到这里就明白，即便不是什么著名景点但依然能不断吸引人前来，无非因为人对美好生活的向往是一致的。查看全文

2月22日，韩国金融监督院发布的数据显示，浦项制铁去年实现营业收入35.011万亿韩元，同比下降6.8%；现代制铁营业收入为22.7332万亿韩元，同比减少2.1%；东国制钢去年营业收入为3.2034万亿韩元，同比下降9.2%；世亚制钢去年营业收入为1.4848万亿韩元，同比减少17.9%。（界面）

以 $n = 1010010$ 为例。从右往左，我们需要计算 $1001$ 的间距 $3$，以及 $101$ 的间距 $2$：

1. 去掉 $n$ 末尾的 $10$，得到 $10100$。这一步可以先计算出 $n$ 的 $\text{lowbit} = 10$，然后把 $n$ 更新成 $\dfrac{n}{2\cdot \text{lowbit}}$。$\text{lowbit}$ 的原理请看 从集合论到位运算，常见位运算技巧分类总结。
2. 计算 $10100$ 的尾零个数加一，得到 $3$，即 $1001$ 的间距。然后把 $10100$ 右移 $3$ 位，得到 $10$。
3. 计算 $10$ 的尾零个数加一，得到 $2$，即 $101$ 的间距。然后把 $101$ 右移 $2$ 位，得到 $0$。算法结束。

class Solution:
    def binaryGap(self, n: int) -> int:
        ans = 0
        n //= (n & -n) * 2  # 去掉 n 末尾的 100..0
        while n > 0:
            gap = (n & -n).bit_length()  # n 的尾零个数加一
            ans = max(ans, gap)
            n >>= gap  # 去掉 n 末尾的 100..0
        return ans

class Solution {
    public int binaryGap(int n) {
        int ans = 0;
        n /= (n & -n) * 2; // 去掉 n 末尾的 100..0
        while (n > 0) {
            int gap = Integer.numberOfTrailingZeros(n) + 1;
            ans = Math.max(ans, gap);
            n >>= gap; // 去掉 n 末尾的 100..0
        }
        return ans;
    }
}

class Solution {
public:
    int binaryGap(int n) {
        int ans = 0;
        n /= (n & -n) * 2; // 去掉 n 末尾的 100..0
        while (n > 0) {
            int gap = countr_zero((uint32_t) n) + 1;
            ans = max(ans, gap);
            n >>= gap; // 去掉 n 末尾的 100..0
        }
        return ans;
    }
};

#define MAX(a, b) ((b) > (a) ? (b) : (a))

int binaryGap(int n) {
    int ans = 0;
    n /= (n & -n) * 2; // 去掉 n 末尾的 100..0
    while (n > 0) {
        int gap = __builtin_ctz(n) + 1;
        ans = MAX(ans, gap);
        n >>= gap; // 去掉 n 末尾的 100..0
    }
    return ans;
}

func binaryGap(n int) (ans int) {
n /= n & -n * 2 // 去掉 n 末尾的 100..0
for n > 0 {
gap := bits.TrailingZeros(uint(n)) + 1
ans = max(ans, gap)
n >>= gap // 去掉 n 末尾的 100..0
}
return
}

var binaryGap = function(n) {
    let ans = 0;
    n /= (n & -n) * 2; // 去掉 n 末尾的 100..0
    while (n > 0) {
        const gap = 32 - Math.clz32(n & -n); // n 的尾零个数加一
        ans = Math.max(ans, gap);
        n >>= gap; // 去掉 n 末尾的 100..0
    }
    return ans;
};

impl Solution {
    pub fn binary_gap(mut n: i32) -> i32 {
        let mut ans = 0;
        n /= (n & -n) * 2; // 去掉 n 末尾的 100..0
        while n > 0 {
            let gap = n.trailing_zeros() + 1;
            ans = ans.max(gap);
            n >>= gap; // 去掉 n 末尾的 100..0
        }
        ans as _
    }
}

复杂度分析

• 时间复杂度：$\mathcal{O}(k)$，其中 $k$ 是 $n$ 二进制中的 $1$ 的个数。
• 空间复杂度：$\mathcal{O}(1)$。

专题训练

见下面位运算题单的「一、基础题」。

分类题单

如何科学刷题？

1. 滑动窗口与双指针（定长/不定长/单序列/双序列/三指针/分组循环）
2. 二分算法（二分答案/最小化最大值/最大化最小值/第K小）
3. 单调栈（基础/矩形面积/贡献法/最小字典序）
4. 网格图（DFS/BFS/综合应用）
5. 位运算（基础/性质/拆位/试填/恒等式/思维）
6. 图论算法（DFS/BFS/拓扑排序/基环树/最短路/最小生成树/网络流）
7. 动态规划（入门/背包/划分/状态机/区间/状压/数位/数据结构优化/树形/博弈/概率期望）
8. 常用数据结构（前缀和/差分/栈/队列/堆/字典树/并查集/树状数组/线段树）
9. 数学算法（数论/组合/概率期望/博弈/计算几何/随机算法）
10. 贪心与思维（基本贪心策略/反悔/区间/字典序/数学/思维/脑筋急转弯/构造）
11. 链表、树与回溯（前后指针/快慢指针/DFS/BFS/直径/LCA）
12. 字符串（KMP/Z函数/Manacher/字符串哈希/AC自动机/后缀数组/子序列自动机）

我的题解精选（已分类）

欢迎关注 B站@灵茶山艾府

给定一个正整数 n，找到并返回 n 的二进制表示中两个 相邻 1 之间的 最长距离 。如果不存在两个相邻的 1，返回 0 。

如果只有 0 将两个 1 分隔开（可能不存在 0 ），则认为这两个 1 彼此 相邻 。两个 1 之间的距离是它们的二进制表示中位置的绝对差。例如，"1001" 中的两个 1 的距离为 3 。

 

示例 1：

输入：n = 22
输出：2
解释：22 的二进制是 "10110" 。
在 22 的二进制表示中，有三个 1，组成两对相邻的 1 。
第一对相邻的 1 中，两个 1 之间的距离为 2 。
第二对相邻的 1 中，两个 1 之间的距离为 1 。
答案取两个距离之中最大的，也就是 2 。

示例 2：

输入：n = 8
输出：0
解释：8 的二进制是 "1000" 。
在 8 的二进制表示中没有相邻的两个 1，所以返回 0 。

示例 3：

输入：n = 5
输出：2
解释：5 的二进制是 "101" 。

 

提示：

• 1 <= n <= 109

据 The Information 爆料，OpenAI 正在开发一款智能音箱，它将配备摄像头，支持类似苹果 Face ID 的人脸识别。你未来可能「看一眼」就能完成购物支付，类似功能目前在小米 Rokid 等智能眼镜已经实现。

在苹果、Meta 都在把 AI 塞进眼镜、手表、吊坠等可穿戴设备时，OpenAI 尝试把摄像头塞进了音箱，能「看见」你和周遭的环境，AI 对你的理解也将从语言延伸到行为，你的作息、习惯、情绪状态，都将让 AI 读懂和拼凑出一个真实的你。

APPSO 先给你快速梳理下 OpenAI 智能音箱的核心信息

• 定价：200-300 美元（约 1450-2200 元人民币）
• 发售时间：最早 2027 年 2 月
• 核心功能：摄像头环境感知、Face ID 级人脸识别、语音购物
• 设计团队：Jony Ive 的 LoveFrom + OpenAI 硬件团队
• 产品矩阵：智能音箱首发，智能眼镜、智能灯后续跟进

「长眼」的智能音箱，你敢用吗

智能音箱这个品类，从 Amazon Echo 到 Apple HomePod，已经卷了快十年。但这些设备的「智能」，往往停留在「能听懂关键词」的层面，离真正的「理解」差着十万八千里。

OpenAI 的解法简单粗暴：给它装上眼睛。

智能音箱内置摄像头，能识别你周边环境，比如桌上摆了什么、旁边在聊什么。还支持类似 Face ID 的面部识别，可以直接刷脸完成购买。这种「所见即所得」的购物体验，目前市面上的智能音箱还做不到，

结合 ChatGPT 去年上线的购物功能——用户可以在对话框里完成从选品到跳转下单的完整流程，这个刷脸购买功能将有望直接服务于「AI 即购物入口」的闭环，成为消费决策链条上的第一道关口。

如无意外，这也将对现有流量分发逻辑造成重大的挑战：Google 靠搜索吃了二十年广告红利，电商平台靠货架逻辑构建起庞大生态，而 OpenAI 想在这两者之前再插入一个新的决策层级。

此外，这款智能音箱还能通过持续的视觉观察判断用户状态——比如发现你在重要会议前夜还在熬夜，会主动提醒你去早点睡。这样一来智能音箱的定位，就从一个智能家居产品，变成了一个 AI 管家中枢。

不过，这种全天候的数据采集，隐私边界在哪里，或许有待 OpenAI 正式发布时给出答案。

想要买到这款产品，还要等一段时间。首款设备最早也要到 2027 年 2 月才能发货。眼镜等其他产品更慢，预计 2028 年才能大规模量产，至于那个智能台灯，原型机有了，但到底会不会发布，还是个未知数。

「含果量」十足的 OpenAI 硬件团队

OpenAI 的硬件野心，从团队规模就能看出来，整整 200 人，而且还在疯狂扩张。其中更令人期待的是，前苹果首席设计官 Jony Ive ，亲自为 OpenAI 操刀产品设计。

这支团队的「含果量」极高，团队由副总裁 Peter Welinder 领导，他此前负责 OpenAI 的新产品探索团队。核心成员包括：

•  Tang Tan：苹果 25 年老将，曾任 iPhone 和 Apple Watch 产品设计主管，直接向苹果硬件主管 John Ternus 汇报，被认为是把 Jony Ive 的设计理念转化为大规模可制造产品的关键人物
• Evans Hankey：苹果前工业设计负责人，曾接替 Jony Ive 执掌苹果设计团队，现为 OpenAI 工业设计负责人
• Scott Cannon：供应链负责人
• Adam Cue：苹果服务主管 Eddy Cue 之子，负责开发驱动 OpenAI 未来设备的软件
• Ben Newhouse：产品研究负责人，正致力于重写 OpenAI 的基础设施以适应音频 AI
• Atty Eleti：负责设备隐私相关工程工作

虽然 Jony Ive 并未直接加入 OpenAI，但他对设计拥有最终决定权，据说每周都会出现在旧金山市中心的办公室。有员工透露，团队讨论时经常会说「Jony 会想要什么」。

然而 Jony Ive 和 OpenAI 的合作并非一帆风顺。据两位知情人士透露，一些 OpenAI 员工抱怨 LoveFrom 修改设计的速度缓慢，且很少分享其构思新设计的流程。这种保密作风和对设计的极致追求，是苹果公司的典型做法——而该团队的许多员工和领导层都来自那里。

为了保持这种运作方式，OpenAI 的设备团队与公司其他部门是分开的。虽然 OpenAI 总部位于米申湾，但设备团队在旧金山市中心杰克逊广场附近的一间办公室办公，离 LoveFrom 的办公室不远。

OpenAI 挖人的手段也很「简单粗暴」——直接用超过 100 万美元的股票期权砸人，薪酬远超苹果标准。据 The Information 报道，OpenAI 今年已经从苹果挖走了 20 多位硬件大牛，而 2023 年这个数字几乎为零。

苹果显然坐不住了。据知情人士透露，苹果去年曾突然取消了原定在中国举行的年度闭门会议——这个会议通常由高管向员工介绍未来产品计划。取消的原因竟然是：「防止更多高管跳槽到 OpenAI」。

内部怎么拧，是执行的事。但有一件事，从一开始就没有悬念——OpenAI 必须做硬件。

软件端 200 亿美元的年收入，已经证明了 AI 是一门好生意，但要让 AI 真正成为水电煤一样的基础设施，必须有一个物理入口。手机这条路走不通——苹果的生态护城河不是一款 AI 新品轻易能够撬动的，其它手机厂商自己也在全力 AI 化，不会将大好的硬件阵地拱手相让。

当然，更根本的问题是，手机的形态本身，可能就不适合做 AI 的宿主。

当 AI 足够聪明时，它不应该被禁锢在一块长方形的玻璃屏幕里，它应该是无处不在的。因此，从音箱、眼镜甚至台灯这些陪伴感更强的品类切入，是 OpenAI唯一，也是最合理的选择。而这一切，或许从 ChatGPT 的产品设计方向上就已经埋下了伏笔。

与 Anthropic 这类深耕企业服务的 AI 公司不同，OpenAI 从一开始就带着强烈的 ToC 基因——ChatGPT 不只是一个工具，它有情绪、有记忆、会共情，Sam Altman 一直在让它变得更像一个「人」。

这背后的逻辑，如今看来相当清晰：一个冷冰冰的 AI 助手，你不会想把它放在卧室里；但一个懂你、记得你习惯、会关心你睡没睡好的 AI，才有资格住进你的生活。

OpenAI 的硬件版图浮出水面

智能音箱只是 OpenAI 硬件全家桶的其中一个，此前 OpenAI 已经被曝出在开发智能眼镜、智能灯、甚至可穿戴别针等多种形态。其中智能眼镜可能要等到 2028 年才能量产——这个时间点，恰好和苹果传闻中的 AI 眼镜撞期。

OpenAI 硬件产品线（APPSO 据曝光信息整理）

• 智能音箱（代号未知）：首款产品，200-300 美元，2027 年 2 月出货
• AI 耳机（代号 Dime/「甜豌豆」）：金属鹅卵石造型，胶囊状耳机置于耳后，2nm 芯片
• 智能眼镜：2028 年量产，与 Meta Ray-Ban、苹果 N50 正面竞争
• 智能灯：原型已准备，是否发布待定
• AI 笔：Sam Altman 多次暗示的「口袋设备」

值得注意的是，OpenAI 的硬件策略似乎经历了调整。此前传闻的 AI 耳机项目「Dime」（甜豌豆），原计划是一款「类手机」全能设备，搭载 2nm 智能手机级芯片。但由于 HBM 内存短缺导致成本过高，OpenAI 被迫调整策略——先推纯音频功能的「阉割版」，等成本下降后再发高配版。

这种「先占坑、后完善」的策略，在硬件圈并不罕见。对 OpenAI 来说，也没有苹果的包袱，不需要将产品打磨到完美才推出市场，即便首款产品不够惊艳，这也是 AI 行业发布产品的一贯风格。

此外 OpenAI 不止挖苹果的人，也盯上了苹果花了几十年打造的供应链。

据知情人士透露，中国主要的 iPhone 和 AirPods 代工厂立讯精密已经拿下了至少一款 OpenAI 设备的组装合同，而负责组装 AirPods、HomePod 以及 Apple Watch 的歌尔股份也在跟 OpenAI 接洽，为未来产品提供扬声器模组等零部件。

Sam Altman 曾在一次采访里提到 OpenAI 硬件的愿景：「智能手机是时代广场，信息轰炸、注意力粉碎。OpenAI 要做的，是一间『湖畔小屋』——让你在需要专注时，能关上门，屏蔽噪音。」

他的核心逻辑在于，AI 硬件不是要取代手机，而是要填补「不方便掏手机」或「需要深度专注」的场景。从这个角度看，智能音箱、AI 笔这类「放在桌上不突兀」的设备，确实比 24 小时佩戴的 AI 吊坠更友好。

但愿景归愿景，现实很骨感。OpenAI 不是第一家想用 AI 硬件重新定义人机交互的公司。Human Pin、Rabbit R1、Friend AI 吊坠……这些「网红 AI 硬件」的销量也都不尽如人意。

此前很多 AI 硬件往往解决的是「伪需求」——它们能做的，手机基本都能做，而且手机做得更好。要改变消费者习惯了近二十年的屏幕交互，接受一个「看不见摸不着」的 AI 助手，挑战不小。

OpenAI 要面对的，不只是市场教育难题，还有巨头的围剿。

据彭博社记者 Mark Gurman 爆料，苹果正在加速推进三款全新的 AI 可穿戴设备：智能眼镜 N50、可穿戴吊坠、摄像头 AirPods，都围绕 Siri 数字助手构建，通过摄像头获取视觉上下文来执行各种操作。

2026 对于 OpenAI 来说，无论是大模型 AI 产品，还是新兴的硬件产品，都会面临一个超级内卷的竞争环境。

即便如此 OpenAI 依然可能给 AI 硬件行业带来一些变化，甚至是分水岭。

它有最豪华的苹果班底、最激进的产品定义、以及 ChatGPT 这个全球份额第一的 AI 产品。但 OpenAI 也面临着所有 AI 硬件共同的困境：如何证明 AI +硬件给体验带来了质的变化，而非只是让产品卖得更贵的又一个理由。

作者：李超凡、莫崇宇

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博

刚在印度 AI 峰会上经历了最尴尬的一幕，Google CEO Sundar Pichai 转头就在今天凌晨官宣了最新模型 Gemini 3.1 Pro。

时机选得，相当精准（doge）。

虽然距离上周 Gemini 3 Deep Think 的更新没几天，但 3.1 Pro 的定位，Google 说得很清楚——专为那些「一个简单答案远远不够」的任务而设计，是解决复杂问题的基础底座。

按惯例，0.1 的版本号更新通常意味着小修小补，然而，在测试模型解决全新逻辑模式能力的 ARC-AGI-2 基准上，3.1 Pro 拿下 77.1%，是上代 3 Pro（31.1%）的两倍多，同时压过了 Anthropic 的 Opus 4.6（68.8%）和 OpenAI 的 GPT-5.2（52.9%）。

其它方面，科学知识测试 GPQA Diamond 拿了 94.3%，智能体类基准 MCP Atlas 和 BrowseComp 分别拿下 69.2% 和 85.9%。

编程能力方面，竞争性编程基准 LiveCodeBench Pro 的 Elo 评分达到 2887，超过 3 Pro 的 2439 和 GPT-5.2 的 2393。SWE-Bench Verified 上，3.1 Pro 拿了 80.6%，和 Opus 4.6 的 80.8% 基本打平。

当然，3.1 Pro 也不是处处碾压。

多模态基准 MMMU Pro 上，上代 3 Pro 反而略胜（81.0% vs 80.5%）；启用工具支持的 Humanity’s Last Exam 里，Opus 4.6 以 53.1% 拿了第一。外界长期批评 Google 工具使用效率不如对手，这次还是没能完全堵上嘴。

第三方知名分析机构 Artificial Analysis 则给出了相当实在的评价。

3.1 Pro 在他们的智能指数里排名第一，比 Opus 4.6 高 4 分；整个测试跑下来总计使用约 5700 万 tokens，完成测试的成本不到 Opus 4.6 的一半。能打又省钱，这个组合还是很香的。

Google DeepMind 首席科学家 Jeff Dean 也转发了一个是用 3.1 Pro 模拟城市规划、设计全新城市的应用，从零生成可交互的规划界面 demo。

Google 官方博客则展示了几个更日常的方向。代码动画方面，3.1 Pro 可以直接根据文字提示生成动态 SVG，因为是纯代码生成而非像素，任意缩放都不失真，文件体积也远小于传统视频。

复杂系统方面，模型直接接入公开遥测数据流，搭出了一个实时追踪国际空间站轨道的航天仪表盘。

更有意思的是两个创意类 demo。

一个是 3D 椋鸟群模拟，不只是生成视觉代码，还支持用手势操控鸟群，并配有随鸟群动态变化的生成音乐；

另一个是把《呼啸山庄》的文学氛围转化成一个现代个人网站，模型没有简单概括情节，而是分析了小说的整体基调，设计出了贴合主人公气质的界面风格。

此外，网友们也贡献了不少精彩的案例。有人让 3.1 Pro 生成一个「鬼怪猎人穿越鬼屋」的动态 SVG 循环动画，结果直接看呆，评价是「Google 这次是认真的」。

还有网友认为让它生成种子破土、根系延伸、茎秆冒出、叶片展开、直到长成完整大树的交互动画，每个生长阶段的过渡都顺滑自然，说这是见过最好的同类效果。

去年从 Anthropic 转投 Google DeepMind 的清华物理系特奖得主姚顺宇也站台宣传：「Gemini 不仅是一个优秀的模型，而且更好的模型正以不可阻挡的方式到来。」

当然，这些 demo 加在一起说的是同一件事：模型能做的事，已经从单纯的回答问题延伸到完成一整套专业或创意工作流了。
价格方面，API 按分级付费，整体和上代 3 Pro 保持一致，但跟 Anthropic Opus 系列比还是相对便宜的。

20 万 tokens 以内，输入 2 美元 / 每百万 tokens，输出 12 美元；超过 20 万 tokens，输入涨到 4 美元，输出 18 美元。搜索功能每月前 5000 次免费，之后每 1000 次查询收费 14 美元。

现在，开发者可以在 AI Studio、Gemini API、Gemini CLI、智能体开发平台 Google Antigravity 以及 Android Studio；企业用户在 Vertex AI 和 Gemini Enterprise；普通用户在 Gemini 应用和 NotebookLM 都能用，后者仅限 Pro 和 Ultra 订阅。

值得注意的是，3.1 Pro 目前只是预览版，Google 大概率是要继续打磨好智能体工作流再推正式版，向外界展示出一副还没使全力的姿态。

至于这种能力渗透到个人层面会发生什么，这让我联想到了 OpenAI 联创 Andrej Karpathy 刚刚发布的推文：

他想用 8 周时间把静息心率从 50 降到 45，计划是设定 Zone 2 有氧总时长目标，配合每周一次 HIIT。为了追踪进展，他花了 1 小时用 vibe coding 做了一个专属仪表盘。

过程比想象中麻烦，Claude 需要对 Woodway 跑步机的云 API 进行逆向工程，提取原始数据，处理筛选，搭出 Web 前端界面，中间还有公制英制单位混用、日历日期对不上这些 bug 需要手动发现并要求修复。

Karpathy 的感叹很犀利，两年前这事得花 10 小时，现在 1 小时。但他更在意的是：这本来应该只需要 1 分钟。
他的判断是，应用商店模式正在过时。

300 行代码、LLM 几秒生成的专属工具，没必要变成一个正经 App 让你去搜索下载。他同时也点了行业的问题：99% 的产品仍然没有 AI 原生的 CLI，还在维护给人看的前端界面，而不是直接提供便于 Agent 调用的 API。

Woodway 跑步机本质上就是个传感器，结果还得让 LLM 去逆向工程它，完全没必要。

把 Jeff Dean 的城市规划 demo 和 Karpathy 的跑步仪表盘放在一起看，其实是同一件事的两面。当普通人花 1 小时就能为自己做一个高度定制的专属工具，由 AI 原生传感器和执行器构成、LLM 负责编排、即兴生成高度定制专属应用的时代，就已经近在眼前了。

附官方博客：
https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-1-pro/

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博

模拟

根据题意进行模拟即可，遍历 $n$ 的二进制中的每一位 $i$，同时记录上一位 $1$ 的位置 $j$，即可得到所有相邻 $1$ 的间距，所有间距取 $\max$ 即是答案。

代码：

###Java

class Solution {
    public int binaryGap(int n) {
        int ans = 0;
        for (int i = 31, j = -1; i >= 0; i--) {
            if (((n >> i) & 1) == 1) {
                if (j != -1) ans = Math.max(ans, j - i);
                j = i;
            }
        }
        return ans;
    }
}

• 时间复杂度：$O(\log{n})$
• 空间复杂度：$O(1)$

---

加餐 & 加练

今日份加餐：【面试高频题】难度 1.5/5，脑筋急转弯类模拟题 🎉🎉🎉

或是考虑加练如下「模拟」题 🍭🍭🍭

题目	题解	难度	推荐指数
6. Z 字形变换	LeetCode 题解链接	中等	🤩🤩🤩
8. 字符串转换整数 (atoi)	LeetCode 题解链接	中等	🤩🤩🤩
12. 整数转罗马数字	LeetCode 题解链接	中等	🤩🤩
59. 螺旋矩阵 II	LeetCode 题解链接	中等	🤩🤩🤩🤩
65. 有效数字	LeetCode 题解链接	困难	🤩🤩🤩
73. 矩阵置零	LeetCode 题解链接	中等	🤩🤩🤩🤩
89. 格雷编码	LeetCode 题解链接	中等	🤩🤩🤩🤩
166. 分数到小数	LeetCode 题解链接	中等	🤩🤩🤩🤩
260. 只出现一次的数字 III	LeetCode 题解链接	中等	🤩🤩🤩🤩
414. 第三大的数	LeetCode 题解链接	中等	🤩🤩🤩🤩
419. 甲板上的战舰	LeetCode 题解链接	中等	🤩🤩🤩🤩
443. 压缩字符串	LeetCode 题解链接	中等	🤩🤩🤩🤩
457. 环形数组是否存在循环	LeetCode 题解链接	中等	🤩🤩🤩🤩
528. 按权重随机选择	LeetCode 题解链接	中等	🤩🤩🤩🤩
539. 最小时间差	LeetCode 题解链接	中等	🤩🤩🤩🤩
726. 原子的数量	LeetCode 题解链接	困难	🤩🤩🤩🤩

注：以上目录整理来自 wiki，任何形式的转载引用请保留出处。

---

最后

如果有帮助到你，请给题解点个赞和收藏，让更多的人看到 ~ ("▔□▔)/

也欢迎你 关注我 和 加入我们的「组队打卡」小群 ，提供写「证明」&「思路」的高质量题解。

所有题解已经加入 刷题指南，欢迎 star 哦 ~

方法一：位运算

思路与算法

我们可以使用一个循环从 $n$ 二进制表示的低位开始进行遍历，并找出所有的 $1$。我们用一个变量 $\textit{last}$ 记录上一个找到的 $1$ 的位置。如果当前在第 $i$ 位找到了 $1$，那么就用 $i - \textit{last}$ 更新答案，再将 $\textit{last}$ 更新为 $i$ 即可。

在循环的每一步中，我们可以使用位运算 $\texttt{n & 1}$ 获取 $n$ 的最低位，判断其是否为 $1$。在这之后，我们将 $n$ 右移一位：$\texttt{n = n >> 1}$，这样在第 $i$ 步时，$\texttt{n & 1}$ 得到的就是初始 $n$ 的第 $i$ 个二进制位。

代码

###Python

class Solution:
    def binaryGap(self, n: int) -> int:
        last, ans, i = -1, 0, 0
        while n:
            if n & 1:
                if last != -1:
                    ans = max(ans, i - last)
                last = i
            n >>= 1
            i += 1
        return ans

###C++

class Solution {
public:
    int binaryGap(int n) {
        int last = -1, ans = 0;
        for (int i = 0; n; ++i) {
            if (n & 1) {
                if (last != -1) {
                    ans = max(ans, i - last);
                }
                last = i;
            }
            n >>= 1;
        }
        return ans;
    }
};

###Java

class Solution {
    public int binaryGap(int n) {
        int last = -1, ans = 0;
        for (int i = 0; n != 0; ++i) {
            if ((n & 1) == 1) {
                if (last != -1) {
                    ans = Math.max(ans, i - last);
                }
                last = i;
            }
            n >>= 1;
        }
        return ans;
    }
}

###C#

public class Solution {
    public int BinaryGap(int n) {
        int last = -1, ans = 0;
        for (int i = 0; n != 0; ++i) {
            if ((n & 1) == 1) {
                if (last != -1) {
                    ans = Math.Max(ans, i - last);
                }
                last = i;
            }
            n >>= 1;
        }
        return ans;
    }
}

###C

#define MAX(a, b) ((a) > (b) ? (a) : (b))

int binaryGap(int n) {
    int last = -1, ans = 0;
    for (int i = 0; n; ++i) {
        if (n & 1) {
            if (last != -1) {
                ans = MAX(ans, i - last);
            }
            last = i;
        }
        n >>= 1;
    }
    return ans;
}

###go

func binaryGap(n int) (ans int) {
    for i, last := 0, -1; n > 0; i++ {
        if n&1 == 1 {
            if last != -1 {
                ans = max(ans, i-last)
            }
            last = i
        }
        n >>= 1
    }
    return
}

func max(a, b int) int {
    if b > a {
        return b
    }
    return a
}

###JavaScript

var binaryGap = function(n) {
    let last = -1, ans = 0;
    for (let i = 0; n != 0; ++i) {
        if ((n & 1) === 1) {
            if (last !== -1) {
                ans = Math.max(ans, i - last);
            }
            last = i;
        }
        n >>= 1;
    }
    return ans;
};

复杂度分析

• 时间复杂度：$O(\log n)$。循环中的每一步 $n$ 会减少一半，因此需要 $O(\log n)$ 次循环。

• 空间复杂度：$O(1)$。

据美国消费者新闻与商业频道网站2月19日报道，美国开放人工智能研究中心（OpenAI）首席执行官萨姆·奥尔特曼表示，中国科技公司在全栈式技术所取得的进步“令人瞩目”。奥尔特曼发表此番言论正值中国正与美国比拼开发通用人工智能，并将其推广至社会各领域之际。报道称，奥尔特曼说，包括人工智能在内，中国在“许多领域”的技术进步速度“快得惊人”。他还说，在某些领域，中国科技公司已接近前沿水平。（参考消息）

1. 适配清单 Checklist

• 开启静态导出：output: 'export'（Tauri 不支持 SSR 那种“必须有服务端”的方案）。 (Tauri)
• tauri.conf.json 里把 frontendDist 指到 ../out（Next 静态导出目录）。 (Tauri)
• 如果你用了 next/image，必须处理图片优化：静态导出下默认的图片优化 API 不可用，最简单就是 images.unoptimized = true。 (Tauri)
• 开发态资源路径要能解析：按官方建议加 assetPrefix，让 dev server 正确解析静态资源（尤其在非 localhost/移动端调试时）。 (Tauri)

2. Tauri 配置：src-tauri/tauri.conf.json

这段的意义是：tauri dev 先跑 Next dev server，再让 WebView 加载 devUrl；tauri build 先跑 Next build（生成 out），再把 out 打包进应用。Tauri CLI 正是按这些字段工作的。 (Tauri)

{
  "build": {
    "beforeDevCommand": "npm run dev",
    "beforeBuildCommand": "npm run build",
    "devUrl": "http://localhost:3000",
    "frontendDist": "../out"
  }
}

(Tauri)

提示：frontendDist 是相对 src-tauri/ 的路径，所以 Next 项目在根目录时通常就是 ../out。

3. Next.js 配置：next.config.mjs

这份配置解决三件大事：

1. 强制静态导出 output: 'export'
2. next/image 走静态导出时禁用默认优化（否则直接报错）
3. 开发态设置 assetPrefix，避免资源解析错误（文档建议）

const isProd = process.env.NODE_ENV === 'production';
const internalHost = process.env.TAURI_DEV_HOST || 'localhost';

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'export',
  images: {
    unoptimized: true,
  },
  assetPrefix: isProd ? undefined : `http://${internalHost}:3000`,
};

export default nextConfig;

(Tauri)

补充理解一下 images.unoptimized：
静态导出下，Next 默认的 Image Optimization API（按需优化）不可用，所以必须禁用或换方案。官方错误说明写得很明确。 (nextjs.org)

4. package.json scripts：确保 Tauri 能“按脚本驱动”前端

你给的 scripts 很标准，Tauri CLI 会调用你在 beforeDevCommand/beforeBuildCommand 里写的命令，所以这里保证能跑就行：

"scripts": {
  "dev": "next dev",
  "build": "next build",
  "start": "next start",
  "lint": "next lint",
  "tauri": "tauri"
}

(Tauri)

5. 运行与打包：你只需要记住两条命令

• 开发：

  • cargo tauri dev（会先执行 npm run dev，再加载 http://localhost:3000） (Tauri)

• 构建：

  • cargo tauri build（会先执行 npm run build，把静态导出生成到 out/，再打包） (Tauri)

Next 的静态导出产物就是 out/，构建后你会看到 out/index.html、out/404.html 等文件结构。 (nextjs.org)

6. 你需要接受的“静态导出”边界

把 Next 变成静态站点后，这些能力要重新规划（否则你会在 build 时报错或运行时缺功能）：

• 不依赖服务端运行时：SSR、需要 Node 运行时的 API Routes、中间件等都要迁移到独立后端服务（保持“客户端 ↔ API”的标准模式）。 (nextjs.org)
• 动态路由要可静态化：要么在构建期生成，要么改成纯客户端拉取数据再渲染（这和 Tauri 的模型更贴）。 (nextjs.org)

7. 常见坑与排查（很实用）

7.1 打包后白屏

优先按顺序查这三项：

• out/ 是否真的生成（执行 npm run build 后是否有 out/index.html）。 (nextjs.org)
• tauri.conf.json 的 frontendDist 是否正确指向 ../out。 (Tauri)
• 资源路径是否被你自定义了 basePath/assetPrefix 导致找不到 JS/CSS（打开 DevTools 看 Network 404）。

7.2 next/image 报错：Image Optimization 不兼容导出

这是经典报错场景，直接按文档处理：images.unoptimized: true 或换图片策略。 (nextjs.org)

7.3 开发态热更新不工作，和 assetPrefix 相关

社区里确实有人反馈：某些组合下 assetPrefix 会影响 hot reload 表现。你如果遇到“编译提示更新但页面不刷新”，可以把它当作已知问题来对待：

• 先尝试升级到更新版本的 Tauri/Next
• 或临时注释 assetPrefix 验证是否是它引起
• 若必须保留资源解析能力，考虑把 dev server host 配置到可直连的内网地址并调整 devUrl（移动端场景更常见） (GitHub)