VSCode工作区配置生效需明确设置层级与作用域：用户级、工作区级、语言级设置优先级递减；禁用editor.detectIndentation以防覆盖tabSize；多根工作区须用${workspaceFolder:xxx}显式指定路径；.code-workspace应使用相对路径并剔除绝对路径和机器名。
工作区配置不是“多加个文件夹”就完事——它真正起效的前提是：你得让 VSCode 明白哪些设置该被覆盖、哪些该被继承，且不能把敏感路径或用户专属参数塞进 settings.json 里提交到 Git。
为什么改了 settings.json 却没生效？
最常见的原因是配置层级冲突。VSCode 的设置有三层：用户级（全局）、工作区级（.vscode/settings.json）、语言级（比如 "[javascript]": {...}），优先级从高到低。如果你在用户设置里开了 editor.formatOnSave，又在工作区里关掉它，那它确实会关；但如果你只改了 editor.tabSize，而用户设置里还开着 editor.detectIndentation，那编辑器可能直接忽略你的 tabSize 值，转而从文件内容里猜缩进。
- 检查是否启用了
editor.detectIndentation—— 它默认为true，会覆盖你手动设的editor.tabSize - 确认你编辑的是项目根目录下的
.vscode/settings.json，而不是用户设置界面导出的 JSON - 用命令面板运行
Developer: Inspect Editor Tokens and Scopes，点一下编辑器里某行，看右下角实际生效的设置来源
launch.json 中的 ${workspaceFolder} 到底指哪个目录？
在单根工作区里，${workspaceFolder} 就是项目根目录；但在多根工作区（.code-workspace）里，它默认指向第一个 folders 项的路径 —— 这很容易导致调试脚本跑错地方。比如你有两个文件夹：./backend 和 ./frontend，launch.json 放在 ./backend/.vscode/ 下，但里面写 "program": "${workspaceFolder}/app.js"，那它其实会去找 ./backend/app.js；可如果这个 launch.json 是放在工作区根目录的 .vscode/ 里（即不在任一子项目内），那 ${workspaceFolder} 就不明确，VSCode 会报错或随机选一个。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 多根工作区中，每个子项目应有自己的
.vscode/launch.json，并用${workspaceFolder:backend}或${workspaceFolder:frontend}显式指定作用域 - 避免把
launch.json放在.code-workspace同级的.vscode/目录里 —— 这个位置不被识别为任何子项目的配置源 -
${workspaceFolder}永远不带尾部斜杠，拼路径时记得加/，比如"${workspaceFolder}/src/index.ts"
要不要把 .code-workspace 文件提交到 Git？
要，但必须剔除绝对路径和机器相关字段。VSCode 生成的 .code-workspace 默认包含完整本地路径（如 "path": "/Users/you/project/backend"），这种写法一克隆就失效。团队共享的工作区文件只应保留相对路径和命名结构。
- 用
"path": "./backend"替代绝对路径，确保所有成员项目结构一致 - 删掉自动生成的
"name"字段（VSCode 有时会写入机器名），改用语义化名称如"name": "backend-api" - 不要在
.code-workspace的settings块里写files.exclude或search.exclude—— 这些应该由各子项目的settings.json控制，否则容易误排除其他根目录下的文件
真正难的不是写配置，而是判断某个行为到底由哪一层设置驱动、以及当多个子项目共用一个工具链（比如统一的 Prettier 版本）时，如何让 settings.json 不重复、不冲突、不漏配 —— 这需要你打开设置搜索框，输入关键词后看右侧“已定义于”的来源标记，而不是靠猜。
