[!info] related notes

• 所属 MOC: DevTools Sources MOC
• 源码映射: Source Map 与 Pretty Print
• 面板: Sources 面板

DevTools Overrides vs Workspaces

一句话关系

Local Overrides
→ 不改服务器，浏览器用本地副本覆盖网络资源

Workspaces
→ 把 DevTools 资源映射到本地项目文件，并保存真实本地修改

二者都能让调试修改跨刷新保留，但 Source of Truth 不同。

Local Overrides

典型场景：

• 线上页面只有生产环境能复现；
• 想快速验证 CSS/JS 修复；
• 想临时改变 response body/header；
• 不方便立刻重新部署。

核心模型：

browser request
→ DevTools local override
→ browser receives modified local version

它是本机调试覆盖层，不会修改服务器内容。

Workspaces

Workspace 把浏览器看到的资源与本地项目目录建立映射。

在映射成功的文件上，DevTools 编辑可以直接写回本地项目文件。

因此它更适合：

• 本地开发服务器；
• DevTools 与源码双向定位；
• 在浏览器现场修改并保存到项目。

当前 Chrome 还支持 localhost 项目通过 /.well-known/appspecific/com.chrome.devtools.json 提供自动 Workspace 连接信息；这仍是本地开发能力，不是生产站点远程写源码机制。

Source of Truth

Overrides

server source
≠ local override copy

验证完后必须把真正修复迁回项目源码。

Workspaces

local project source
= mapped writable source

但 Git/版本控制仍由项目工作流负责。

常见误区

• Override 验证成功后忘记修改正式源码；
• 把 Overrides 目录提交成产品源码；
• 认为 Workspace 自动替代 Git；
• 在错误的 generated file 上保存修改，而真正 Source of Truth 是 TypeScript/SFC 源文件。

学习检查

1. Overrides 与 Workspaces 的 Source of Truth 有什么差异？
2. 为什么 Overrides 特别适合验证只在生产环境出现的问题？
3. Workspace 为什么仍不能替代 Git？
4. 如果页面运行的是 bundle.js，但源码是 TypeScript，应避免把长期修复写到哪一层？
5. 自动 Workspace connection 为什么只应该理解为本地开发便利，而不是生产环境写文件能力？

官方资料

• https://developer.chrome.com/docs/devtools/automatic-workspaces