一文科普 Claude Code 源码泄露案：高达 51 万行的 AI 底座，是怎么被一个 .map 文件扒光底裤的？

近期，AI 领域爆发了一场令人震惊的安全事件，顶级大模型厂商 Anthropic 因为一次极度低级的工程配置失误，将其核心产品的底层逻辑彻底暴露在公众视野中。这起轰动全网的 Anthropic 源码泄露事件，并非源于任何高阶的黑客渗透攻击，而是由前端构建流水线中一个不起眼的调试映射文件所引发。在向公众注册表发布包时，开发团队意外地将包含完整内联源码的 cli.js.map 文件打包上传，直接导致了灾难级的 Source Map 泄露。在这个体积达 57MB 的 JSON 文件内部，毫无加密地封装着高达 51 万行的原始 TypeScript 和 React 代码。任何人只需编写一段基础的源码提取脚本，就能精准解析出文件中的映射字段，瞬间还原出包含 1900 多个核心业务源文件的完整目录树。这次泄露不仅将极其复杂的 AI Agent 架构、底层工具调用逻辑以及高度机密的系统级提示词（如备受关注的 Claude Mythos 5.0）全盘托出，更向整个软件工程界敲响了震耳欲聋的警钟。这起由 Claude Code 源码泄露 map 文件引发的工程血案，深刻暴露了现代前端与 Node.js 开发链条中长期被忽视的盲区，它无可辩驳地证明了，在缺乏严格自动化审查的 npm 发布安全机制下，即便是估值数百亿的科技巨头，其最核心的商业机密也可能因为一行忘记关闭的编译配置而瞬间毁于一旦。

事件速览：Anthropic 犯了什么低级错误？

近期，AI 社区被一场突如其来的“开源”狂欢点燃——Claude Code 的底层源代码在全网彻底曝光。然而，这并非源于任何高明的黑客攻击，而是一次极为低级的工程发布失误。

正如事件发现者 Chaofan Shou（@Fried_rice）所指出的，Anthropic 的工程师在向 npm 注册表发布 @anthropic-ai/claude-code 包时，意外地将用于开发调试的 Source Map 文件一并打包进了生产版本中。

这次配置失误直接导致了堪称灾难级的代码泄露。以下是本次事件的核心数据摘要：

• 庞大的代码规模：高达 51.2 万行基于 TypeScript 和 React 编写的原始代码被一览无余。
• 完整的文件结构：泄露内容包含 1900+ 个核心业务源文件，项目的完整目录结构、甚至是内部员工专属的“卧底模式”等隐藏逻辑均被原样扒出。
• 致命的罪魁祸首：所有这些机密信息，全都毫无加密地藏在一个体积约 57MB 的 cli.js.map 文件中。

仅仅因为发布流水线上的一个疏忽，这个 .map 文件就将 Claude Code 内部的核心商业机密公之于众。那么，究竟什么是 .map 文件？它又为什么会把 51 万行源码“一字不差”地揣在肚子里？接下来的技术科普将为你揭开这个前端构建机制中的致命隐患。

技术科普：.map 文件是什么？为什么会包含源码？

在现代前端和 Node.js 开发中，为了提升性能和执行效率，开发者通常会使用 Webpack、Vite 或 TSC 等构建工具，将数十万行的 TypeScript 或 React 源码进行编译、压缩和混淆，最终打包成体积小巧、机器友好的 .js 文件。

但这带来了一个致命的调试痛点：一旦生产环境报错，错误堆栈只会指向压缩后代码的某一行（比如第 1 行第 30000 个字符），内部变量名也全变成了 a, b, c，开发者根本无从查错。

为了解决这个问题，Source Map 应运而生。打个比方，.map 文件就像是一本“翻译对照表”或“字典”。它是一个独立的 JSON 格式文件，里面存储着位置映射信息，能够将压缩、混淆后的代码精准还原回开发者编写的原始代码位置。在正常的开发调试中，当开发者打开浏览器的开发者工具时，工具会自动读取这个文件，重构出可读的目录结构供除错使用。

为什么一个映射文件会包含全部源码？

标准的 Source Map 实际上只需记录“文件路径”和“行号列号”的映射关系（即 mappings 字段）。但在实际工程中，为了让调试工具在无法通过网络请求获取原始源文件时依然能展示源码，大多数构建工具都提供了一个便利但也极具风险的配置项：内联源码（Inline Sources）。

当打包工具未被正确配置（例如在生产构建中忘记关闭该选项）时，它不仅会生成位置映射，还会将所有原始代码的完整字符串，直接硬编码塞进 .map 文件中的 sourcesContent 数组字段里。

我们可以通过一个极简的 .map JSON 代码片段来直观理解它的内部结构：

{
  "version": 3,
  "file": "cli.min.js",
  "sourceRoot": "",
  "sources": [
    "src/QueryEngine.ts",
    "src/utils/auth.ts"
  ],
  "sourcesContent": [
    "export class QueryEngine { / 这里是几万行原始 TypeScript 源码的完整字符串 / }",
    "export function login() { / 原始工具函数源码 / }"
  ],
  "names": ["QueryEngine", "login"],
  "mappings": "AAAA,CAAA,G... (由 VLQ 编码组成的位置映射字符串)"
}

在这个结构中，导致源码泄露的罪魁祸首就是这两个相互绑定的数组：

1. sources：记录了所有原始文件的目录和文件名。
2. sourcesContent：记录了与 sources 数组索引严格一一对应的完整原始代码。

正如开发者在复盘 Claude Code 泄露事件 时指出的那样，这个高达 57MB 的 cli.js.map 文件，本质上就是一个装满源码的巨大 JSON。获取这些代码完全不需要任何高深的“反编译”或“反混淆”技术，因为 sourcesContent 里存放的就是一字不差的原始代码。只要读取这个 JSON 文件，按索引将代码字符串写回对应的文件路径，整个 51 万行的 AI 底座就会被完整还原。

硬核复现：如何从 cli.js.map 提取 51 万行源码？

正如前文所述，这次泄露不需要任何高深的黑客技术，也不涉及反编译或反混淆。面对一个高达 57MB 的 cli.js.map 文件（内部包含 4756 个源文件，其中 1906 个为 Claude Code 自身的 TypeScript/TSX 源码），开发者只需要编写一段简单的脚本，利用 JSON 解析即可将源码连同完整的目录结构“扒”下来。

这里提供一段基于 Node.js 的提取脚本示例。它的核心逻辑非常直接：读取 JSON，将 sources 数组（文件路径）与 sourcesContent 数组（源码内容）进行一一对应，最后写入本地文件系统。

const fs = require('fs');
const path = require('path');

// 1. 读取并解析 .map 文件
console.log('正在加载并解析 cli.js.map...');
const mapFile = fs.readFileSync('cli.js.map', 'utf8');
const mapData = JSON.parse(mapFile);

const outputDir = path.join(_dirname, 'claudecodeextracted');

// 2. 遍历 sources 数组
mapData.sources.forEach((sourcePath, index) => {
  // 获取对应的源码内容
  const content = mapData.sourcesContent ? mapData.sourcesContent[index] : null;

if (!content) return; // 忽略没有源码内容的文件

// 3. 边界情况处理：清理虚拟路径与相对路径
  // 移除构建工具注入的虚拟协议头部，如 webpack:// 或 node:
  let cleanPath = sourcePath.replace(/^(webpack:\/\/(?:\/NE\/)?|node:|file:\/\/\/)/, '');

// 移除路径中可能导致目录穿越的相对路径前缀 (如 ../../)
  cleanPath = cleanPath.replace(/^(\.\.\/)+/, '');

// 处理特定作用域包或带有特殊字符的路径
  cleanPath = cleanPath.replace(/^\//, '');

// 组装最终的绝对路径
  const targetPath = path.resolve(outputDir, cleanPath);

// 安全校验：确保最终路径严格在 outputDir 内，防止恶意覆盖系统文件
  if (!targetPath.startsWith(outputDir)) {
    console.warn([跳过] 异常路径: ${sourcePath});
    return;
  }

// 4. 重建目录树并写入文件
  const dirName = path.dirname(targetPath);
  fs.mkdirSync(dirName, { recursive: true });
  fs.writeFileSync(targetPath, content, 'utf8');
});

console.log('✅ 51万行源码已成功还原至 claudecode_extracted 目录！');

为了确保提取过程顺利，以上脚本在实现时重点处理了以下四个关键步骤：

1. 读取与解析 JSON：使用 fs.readFileSync 将 57MB 的 .map 文件一次性读入内存并执行 JSON.parse()。虽然文件较大，但在现代 Node.js 环境下，几十兆的 JSON 解析完全在 V8 引擎的内存承受范围内，无需使用复杂的流式解析（Stream）。
2. 数组索引映射：在 Source Map 标准中，sources 数组与 sourcesContent 数组的索引是强绑定的。脚本通过 forEach 的 index 参数，精准提取出每一条路径对应的原始 TypeScript 代码。
3. 处理路径边界情况（避坑关键）：这是提取脚本中最容易出错的一环。构建工具（如 Webpack、Vite 或 TSC）在生成 Source Map 时，往往会在 sources 中硬编码一些虚拟路径或相对路径。

• 虚拟路径协议：例如 webpack://[name]/ 或 node:internal/，如果不加清洗直接传给文件系统，会导致路径解析错误。脚本通过正则将其剥离。
• 目录穿越风险（Path Traversal）：部分路径可能以 ../../node_modules/ 开头。如果不加过滤直接执行写入，极易导致文件被写入到项目目录之外，甚至覆盖系统文件。脚本通过剔除前置的 ../ 并配合 startsWith 进行严格的安全校验来规避此问题。

1. 还原目录树并写入：由于源码包含复杂的嵌套结构（如 src/components/ 或 src/utils/），在写入文件前，必须先使用 path.dirname 获取目标文件的所在目录，并调用 fs.mkdirSync(..., { recursive: true }) 递归创建所有缺失的父级文件夹，最后再将一字不差的源码字符串写入硬盘。

运行这段脚本后，原本被打包成黑盒的 AI 代理底层架构、系统提示词（System Prompts）以及工具调用逻辑，就会以最原始的 TypeScript 目录树形态，完整地展现在开发者的编辑器中。

扒开底裤：Claude Code 的 AI Agent 架构剖析

当一份包含 1900 多个 TypeScript 源文件、总计高达 51.2 万行代码的工程库毫无保留地展现在开发者面前时，我们看到的绝不仅仅是一个简单的 API 套壳包装器（Wrapper）。从这些未混淆的源码中可以清晰地透视出，Anthropic 实际上在构建一个庞大且严密的“Agent 操作系统”。

目前市面上大多数开源 Agent 往往依赖于基础的 Prompt 拼接与线性的工具调用循环，而 Claude Code 展现出的则是一套极其成熟的生产级 AI Agent Harness（代理脚手架）设计。其工程复杂度体现在对系统边界的严格划分与状态管理的极致追求上：从底层的沙箱隔离、多智能体协同路由，到毫秒级的启动延迟优化，再到用小模型监管大模型的动态权限收敛机制，无不彰显着第一梯队 AI 团队的工程底蕴。

为了真正理解这套工业级架构的精髓，我们必须剥离表层的业务逻辑，直接深入其运转的底层骨架。接下来的部分，我们将重点拆解支撑这套“Agent OS”的两大核心技术支柱：

• Agent 的中枢大脑与执行流：深入剖析庞大的 QueryEngine 是如何与 Task System 配合，完成从复杂指令解析、意图路由到多子智能体（Sub-agent）任务分发的完整闭环。
• 反直觉的终端渲染方案：探讨 Anthropic 团队为何在一个纯命令行工具（CLI）中，引入看似庞大的 React 与多层前端状态管理机制，并以此重塑高并发大模型流式输出的终端交互体验。

核心驱动力：QueryEngine 与 Task System 设计

要理解 Claude Code 是如何将人类模糊的自然语言指令转化为精确的本地操作，就必须深入其最核心的调度大脑。泄露的源码表明，这并非一个简单的“接收输入-调用 API-输出结果”的线性脚本，而是一个基于状态机与 Generator（生成器）模式构建的复杂 Agent 循环。

在这个架构中，真正负责会话管理与任务拆解的核心模块是 QueryEngine（查询引擎）与底层的 Task System（任务/工具系统）。

REPL 与 QueryEngine 的双轨路由模式

在源码的架构设计中，开发者针对不同的运行环境设计了两条截然不同的入口路径，但最终都收敛于同一个核心执行引擎 query()：

1. 交互式 REPL 模式：面向终端用户。用户的输入首先被 REPL 循环捕获。在这里，系统会优先拦截 Slash commands（斜杠命令）。例如，当检测到 /clear 或 /help 等指令时，路由分发器会直接在本地处理并更新 UI 状态，而不会消耗大模型 Token。只有当判断为自然语言任务时，REPL 才会通过 for await (const event of query({...})) 直接唤醒底层的 query() 生成器。
2. Headless/SDK 模式：面向自动化 CI/CD 或 IDE 集成。在这个模式下，高达 4.6 万行的 QueryEngine 类成为了整个会话的状态持有者。它不负责 UI 渲染，而是专注于维护对话上下文、权限拦截记录以及 Token 用量追踪。

从暴露的代码片段可以看出，QueryEngine 内部维护了极度严谨的状态管理：

export class QueryEngine {
  private mutableMessages: Message[]               // 核心消息历史队列
  private abortController: AbortController         // 全局中断控制，用于随时掐断失控任务
  private permissionDenials: SDKPermissionDenial[] // 权限拒绝追踪记录
  private totalUsage: NonNullableUsage             // 累计 Token 消耗监控
  private readFileState: FileStateCache            // 本地文件系统状态缓存
  private discoveredSkillNames = new Set<string>() // 动态技能发现与注册追踪
}

Agent 核心循环：从理解指令到执行任务的生命周期

当指令穿透路由层进入 query() 函数后，系统便启动了一个完整的 Agent 生命循环。结合泄露的工程细节，我们可以将 Claude Code 拆解复杂任务的流程结构化为以下几个关键步骤：

• Step 1: System Prompt 动态编译
  系统并不会使用静态的提示词，而是将 Prompt 模块化。静态段（如通用指令）会被跨用户缓存以节省成本，而动态段（如当前工作目录状态、Git 状态）则在每次会话时实时拼接。源码中甚至暴露了一个名为 DANGEROUS_uncachedSystemPromptSection() 的函数，暗示了动态拼装过程中对缓存污染的严格防范。
• Step 2: LLM 流式推理与拦截
  编译好的上下文被发送至 Claude API。此时系统进入流式监听状态，等待模型输出思考过程（Chain of Thought）或具体的工具调用指令（tool_use）。
• Step 3: 流式工具执行（StreamingToolExecutor）
  这是 Claude Code 工程实现上的一大亮点。传统的 Agent 框架通常会等待 LLM 完整输出 JSON 后再解析执行，但 Claude 引入了 StreamingToolExecutor。一旦在流式响应中探测到完整的工具参数闭环，系统就会在 LLM 仍在输出的同时，异步触发本地工具执行，极大地抹平了 I/O 延迟。
• Step 4: 结果回收与上下文压缩（Compaction）
  工具执行完毕后，tool_result 会被重新喂给 LLM 以决定下一步动作。如果循环执行导致上下文 Token 逼近阈值，系统会自动触发内部的 compact 机制，对早期的废话或冗长的命令输出进行摘要折叠，防止上下文窗口爆炸。

Task System：40+ 工具的编排与并发

大模型的决策最终需要落地到物理操作，这就依赖于 tools/ 目录下的 40 多个独立工具模块。这些工具覆盖了文件读写、Bash 执行（基于沙箱）、LSP 协议通信、以及子 Agent 调度等。

在任务系统的设计上，Anthropic 展示了极高的防御性编程思维。每个工具不仅定义了严格的输入 Schema，还绑定了四级权限模型（default、auto、bypass、yolo）。更值得一提的是，源码中的 toolOrchestration.ts 揭示了系统具备智能分区并发的能力：当 LLM 决定同时读取多个文件或执行多个互不干涉的查询时，任务系统能够将这些 tool_use 请求并行分发给多个子线程执行，而不是低效的串行排队。这种设计使得 Claude Code 在处理大型代码库重构时，展现出了远超常规套壳脚本的执行效率。

意料之外的技术栈：CLI 中的 React 与多层状态管理

在传统的 Node.js 命令行工具开发中，工程师们通常会选择 commander 处理路由，配合 chalk 输出彩色文本，最多加上 ora 来展示加载动画。然而，此次泄露的源码揭示了 Anthropic 团队一个略显激进却极其务实的技术选型：在 CLI 终端渲染层中引入了 React 与 Ink 框架。

对于一个纯命令行工具而言，引入完整的 React 运行时似乎显得过于笨重。但当你打开高达 5005 行的 screens/REPL.tsx 文件时，这种架构设计的必要性便不言而喻。

为什么 CLI 需要 React？声明式与命令式的降维打击

普通的 CLI 工具通常是线性的“输入-执行-输出”模型，而 Claude Code 本质上是一个运行在终端里的复杂交互式系统。在大模型流式输出（Streaming）和多工具并发执行的场景下，终端的 UI 状态会变得异常复杂。

在 Claude Code 的实际运行中，Agent 可能在同一时间处理多个异步任务：一边逐字流式打印大模型的回复，一边展示底层工具（如本地文件搜索或执行 Bash 命令）的实时进度条，同时还要准备渲染代码修改的 Diff 视图。如果采用传统的命令式终端输出，维护这些高频局部刷新的状态将迅速演变成难以维护的“意大利面条代码”。而 React 的组件化思想和虚拟 DOM 机制，完美接管了终端字符矩阵的重绘逻辑。

多层状态管理：维持长对话上下文的基石

除了渲染层的 React，源码还暴露了其极其精细的前端状态管理机制。Anthropic 并没有使用庞大的 Redux，而是采用了一种极简的 Zustand 风格自定义 Store（位于 state/store.ts）。

在长时间的 AI 对话中，多层状态管理的工程价值主要体现在以下几个层面：

1. 会话级状态（Session State）： 维护多轮对话的完整历史、Prompt Cache（提示词缓存）的命中情况以及 Token 消耗统计。这些数据需要跨越单个 Query 的生命周期持久存在。
2. 执行级状态（Execution State）： 记录当前大模型生成的思维链（Chain of Thought）、工具调用的请求与响应参数。
3. UI 渲染状态（Render State）： 控制终端界面上的折叠面板、高亮光标位置、加载动画帧等纯视觉元素。

案例说明：当用户让 Claude "重构当前目录下的所有测试文件" 时，Agent 会派生出多个并行的工具调用动作。此时，状态管理中心会为每个工具分配独立的执行状态节点。React 监听到状态树的变更后，能在终端的固定区域内动态更新每个文件的重构进度，而不会打断屏幕下方用户正在输入的新指令。这种将“业务逻辑状态”与“UI 渲染状态”严格解耦的设计，是保证终端多任务并发时不串位、不崩溃的关键。

架构师视角的评估：利弊权衡

从工程架构的角度来看，在 CLI 中重度使用前端技术栈是一把双刃剑：

• 优势：极大地提升了复杂终端 UI 的可维护性，使得前端工程师能够零成本将 Web 端的复杂交互经验迁移到 CLI 开发中；配合激进的 Bun 运行时，能够有效弥补 React 带来的部分性能损耗。
• 风险与挑战：React 运行时的引入不可避免地增加了 CLI 的冷启动时间和内存占用。此外，对于习惯了纯后端或脚本语言的开发者而言，理解生命周期钩子（Hooks）和组件重渲染逻辑存在一定的学习曲线。

总体而言，Anthropic 的这一选型证明了：当 AI Agent 的能力边界从“单次问答”扩展到“持续在线的自动化协作者”时，其交互载体的工程复杂度已经完全等同于一个现代单页应用（SPA）。采用 React + Ink + 多层状态管理，并非为了炫技，而是应对极端工程复杂度下的最优解。

彩蛋与特性开关：Claude Mythos 5.0 是什么？

在现代前端与 Node.js 工程实践中，为了支持主干开发（Trunk-based Development）、A/B 测试以及灰度发布，开发团队通常会深度依赖 Feature Flags（特性开关）。通过在代码中预埋逻辑分支，官方可以在不重新发布客户端版本的情况下，动态控制新功能的开启与关闭。而这次 .map 文件泄露事件，不仅扒光了 Claude Code 的底层架构，还意外充当了 Anthropic 内部产品路线图的“剧透机器”。

在被还原的 51 万行 TypeScript 源码中，最早发现该漏洞的开发者（如安全研究员 Chaofan Shou）以及社区的极客们，在状态管理和配置解析层中挖出了多个尚未对公众开放的特性开关。其中最引人瞩目的，莫过于代码中赫然出现的 Claude Mythos 5.0 引用。

关于 Claude Mythos 5.0 究竟是什么，目前代码层面揭示了以下几种技术可能性：

• 新一代模型代号：在 AI 行业，内部代号往往带有强烈的隐喻色彩（如 OpenAI 的 Orion 或 Strawberry）。结合上下文，这极有可能是 Anthropic 正在内部测试的下一代大模型（或许是 Claude 4.0，或者是某种具备更强推理能力的特定版本）的对接标识。
• 内部 Agent 架构版本：源码中暴露了复杂的 QueryEngine（查询引擎）和 Task System（任务系统）。Mythos 5.0 也可能并非指代语言模型本身，而是指代这套负责调度、工具调用（Tool Use）和多层状态管理的底层 Agent 框架的内部大版本号。
• 高级 Slash Commands 扩展：代码中还包含了一系列处于灰度测试中的 Slash 命令（/ 指令）。Mythos 可能是为了支持更复杂、多模态或长上下文工作流而设计的一套全新交互系统。

从工程机制来看，这次泄露为我们提供了一个观察顶尖 AI 公司如何做商业软件灰度发布的绝佳窗口。源码中的 if (flags.enableMythos5) 或类似的鉴权逻辑，清晰地展示了 Anthropic 是如何将实验性功能打包在生产环境的客户端中，并仅对内部员工或特定白名单用户下发配置的。

避坑指南：区分“代码事实”与“产品猜测”

在吃瓜和探索时，工程师必须保持严谨的求证态度。代码中存在某个变量，绝不等于官方即将发布该产品。

在大规模商业软件的演进中，Feature Flags 经常被用来包裹废弃的实验性功能、黑客马拉松产物，或是由于商业原因被无限期搁置的废案。我们能够 100% 确认的“事实”是：Anthropic 内部确实在开发或测试名为 Mythos 5.0 的系统，并已经将其接口逻辑集成到了当前的 CLI 工具中；但它最终是否会作为公共产品线面世、何时面世，依然属于“猜测”范畴。不要将基于变量名的合理推测，当成确凿的官方发布计划来传播。

亡羊补牢：开发者如何避免 Source Map 泄露惨案？

Anthropic 这次高达 51 万行核心代码的泄露，并非源于多么高深的零日漏洞（0-day）攻击，而仅仅是一个极其低级的 npm 发布失误——意外将包含 sourcesContent 的 cli.js.map 文件打包上传。对于普通开发者和企业团队而言，这个惨痛的教训再次敲响了警钟：在现代前端与 Node.js 的工程化构建流程中，源码泄露的风险几乎无处不在。

在生产环境中，.map 文件（Source Map）本质上就是一张“藏宝图”。它精确地记录了压缩、混淆后的执行代码与原始 TypeScript/JavaScript 代码之间的映射关系。一旦随安装包分发或暴露在公网静态目录中，任何人都可以利用现成的还原工具，完美提取出包含完整变量名、业务逻辑、代码注释甚至内部 API 路径的原始工程。这并非个例，此前连苹果 App Store 的前端架构也曾因遗漏 Source Map 而遭遇过底裤被扒光的尴尬局面。

要彻底杜绝此类惨案，仅仅在开发规范里强调“注意安全”是远远不够的，必须通过工程化的手段将风险掐断在构建与发布环节。接下来，我们将从具体的工程实践出发，为你提供一份可以直接落地、涵盖主流构建工具（TSC、Vite、Webpack）的防泄露配置指南与最佳实践清单，帮助你的团队真正做到防患于未然。

构建工具配置指南：TSC / Vite / Webpack

前端部署遗漏 SourceMap 是现代前端和 Node.js 工程中最容易踩的坑之一。为了彻底阻断类似 Anthropic 源码泄露的风险，我们需要在构建工具层面进行严格的管控。核心原则只有一个：永远不要将包含 sourcesContent 的 .map 文件发布到公共 npm 仓库或部署到静态资源服务器。

以下是针对主流构建工具的具体防泄露配置指南。

1. TypeScript (TSC)

在使用 tsc 编译 Node.js 模块或类库时，tsconfig.json 中的两个配置项直接决定了你的源码是否会被“打包赠送”。

• sourceMap：决定是否生成 .js.map 文件。
• inlineSources：如果设为 true，TypeScript 会将原始的 .ts 源码以字符串形式直接硬编码到 .map 文件的 sourcesContent 数组中。这正是导致 Claude Code 底裤被扒光的罪魁祸首。

安全配置示例：

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "CommonJS",
    "outDir": "./dist",
    // 生产环境建议直接关闭
    "sourceMap": false, 
    // 严禁在生产环境设为 true，否则源码将直接嵌入 map 文件
    "inlineSources": false 
  },
  "exclude": ["node_modules", "*/.spec.ts"]
}

工程建议：如果是发布到 npm 的闭源商业包，建议将 sourceMap 设为 false。如果是为了排查线上报错必须生成 Map，请确保在 package.json 的 files 字段或 .npmignore 中显式排除 */.map 文件。

2. Webpack

Webpack 的 Webpack 安全配置中，最致命的错误就是在生产环境中保留了 devtool: 'source-map'。这不仅会生成完整的 .map 文件，还会在打包产物的末尾追加 //# sourceMappingURL=... 注释，引导浏览器开发者工具自动下载并还原源码。

为了兼顾线上错误监控与代码安全，建议[合理配置 devtool](https://juejin.cn/post/7436410166515449856) 为 hidden-source-map 或直接禁用。

安全配置示例：

// webpack.config.js
module.exports = (env, argv) => {
  const isProduction = argv.mode === 'production';

return {
    // ... 其他配置
    // 生产环境使用 hidden-source-map，开发环境使用 eval-source-map
    devtool: isProduction ? 'hidden-source-map' : 'eval-source-map',
    optimization: {
      minimize: isProduction,
    }
  };
};

解析：hidden-source-map 会生成独立的 .map 文件，但不会在压缩后的 JS 文件末尾添加映射注释。这意味着即使 .map 文件不小心被传到了服务器，攻击者也无法通过浏览器控制台直接看到源码，增加了一层发现难度。

3. Vite / Rollup

Vite 底层基于 Rollup，其 Source Map 行为由 vite.config.ts 中的 build.sourcemap 控制。与 Webpack 类似，它也支持生成隐藏的 Map 文件。

安全配置示例：

// vite.config.ts
import { defineConfig } from 'vite';

export default defineConfig(({ command, mode }) => {
  const isProduction = mode === 'production';

return {
    build: {
      // false: 不生成 (最安全)
      // 'hidden': 生成 map 文件但不追加 //# sourceMappingURL 注释
      sourcemap: isProduction ? 'hidden' : true,

rollupOptions: {
        output: {
          // 确保产物命名包含 hash，避免被轻易猜解
          entryFileNames: assets/[name].[hash].js,
          chunkFileNames: assets/[name].[hash].js,
        }
      }
    }
  };
});

4. 最佳实践：将 Source Map 接入错误监控平台

无论使用哪种构建工具，最彻底的安全策略是将 Source Map 的生成与分发流程物理隔离。不要把 .map 文件和 JS 产物放在同一个目录下进行发布（例如 npm publish 或 Docker 镜像构建）。

标准的安全工作流（以 Sentry 为例）：

1. 构建阶段：开启 hidden-source-map，让构建工具在 dist 目录下生成包含 sourcesContent 的 .map 文件。
2. 上传阶段：在 CI/CD 管道中，使用 Sentry CLI（或其他 APM 工具的 SDK）将 dist 目录下的 .map 文件连同版本号（Release Tag）安全上传到监控平台。
3. 清理阶段：上传成功后，立即执行 `rm -rf dist//.map`*。
4. 发布阶段：将清理掉 .map 文件后的纯净 dist 目录打包发布到 npm 或部署到生产服务器。

通过这种“阅后即焚”的 CI/CD 流程，既保证了线上报错时能够在 Sentry 后台精准定位到源码的行和列，又从根本上杜绝了 .map 文件流入外部环境的可能。

NPM 发布安全防护策略

构建环节的配置固然重要，但 NPM 发布环节才是阻断敏感文件外泄的最后一道防线。Anthropic 此次将体积高达 57MB 的 cli.js.map 连同 1900 多个 TypeScript 源文件一起打包发布，本质上是一个经典的发布权限失控问题。除了在 Webpack 或 Vite 等构建工具中控制产物，开发者必须在发布环节建立拦截机制，确保即使构建产物中意外生成了 Source Map，也能将其拦截在本地。

在 NPM 包的发布控制上，开发者通常面临“黑名单”与“白名单”两种机制的选择：

• 黑名单机制（.npmignore 或回退到 .gitignore）：通过声明要排除的文件来控制发布内容。这种机制的致命缺陷在于极易遗漏。随着项目迭代，新增的敏感文件（如测试脚本、内部配置文件或意外生成的 .map 文件）如果不专门添加到黑名单中，就会被默认推送到公共注册表。
• 白名单机制（package.json 中的 files 数组）：显式声明允许发布的文件或目录（例如 ["dist", "bin", "README.md"]）。这种机制从根本上切断了未知文件外泄的可能——无论工作区或构建目录中多出了什么意外产物，只要不在白名单内，就绝对不会被打包上传。

在生产级项目的安全实践中，强烈推荐使用 files 字段进行严格的白名单发布控制，避免依赖黑名单带来的潜在风险。

此外，仅靠静态配置仍可能存在人为疏忽，在实际执行 npm publish 之前引入自动化检查与预览工具，是防患于未然的必要手段：

• 使用 npm pack --dry-run：在发布前执行该命令，NPM 会在本地模拟打包过程，并详细输出即将被打入 tarball 的所有文件列表及其体积大小。如果 Anthropic 的发布流程中包含这一步，那个异常庞大的 57MB 映射文件绝对会无所遁形。
• 引入 npx publint 校验：将 publint 等包质量与安全检查工具集成到 CI/CD 的发布流水线（如 GitHub Actions）中。在执行发布指令前，通过自动化脚本校验包的结构、依赖和包含文件，确保没有携带多余的调试产物。

总结来说，NPM 安全发布的黄金法则只有八个字：默认拒绝，最小权限。不要假设你的代码混淆和构建配置永远完美，在发布这最后一道关卡严格收缩权限，才能彻底避免核心 AI 底座被一个配置文件“扒光底裤”的惨剧。