团队VSCode颜色配置应仅将workbench.colorCustomizations、editor.tokenColorCustomizations、editor.semanticTokenColorCustomizations三项写入项目级.vscode/settings.json并提交Git，禁用用户级配置，确保语义着色一致且可复现。
团队协作中，VSCode 颜色配置必须进版本控制，否则“你看着正常，我打开全是乱码”是常态。 核心矛盾不在配色本身，而在 settings.json 的作用域和加载优先级 —— 用户级配置不共享，工作区级配置才可提交，且必须明确排除敏感字段。
怎么把颜色配置放进 Git 仓库（.vscode/settings.json）
直接把用户全局的 settings.json 拷进项目会出问题：它包含大量与机器环境强绑定的设置（如 git.path、terminal.integrated.profiles），一提交就污染他人环境。
- 只提取与视觉一致性直接相关的键：
workbench.colorCustomizations、editor.tokenColorCustomizations、editor.semanticTokenColorCustomizations - 新建或编辑项目根目录下的
.vscode/settings.json，仅保留上述三组配置，其他全删 - 确保
editor.tokenColorCustomizations中的值是合法 CSS 颜色字符串（如"#cc7a8b"），不能是变量或表达式 - 提交前检查：在干净的新克隆仓库中用 VSCode 打开，确认颜色立即生效，且无报错提示
为什么 settings.json 里 colorTheme 不能写成 "Dark+"？
colorTheme 是主题名，不是 ID。VSCode 内置主题的 ID 和显示名不一致，硬写显示名会导致配置失效或回退到默认主题。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 正确写法是查扩展市场或主题文档里的 ID，例如 Dark+ 对应
"default-dark-plus"，Light+ 对应"default-light-plus" - 第三方主题更需严格匹配，比如
"Material Theme"的 ID 是"material-theme"，大小写、连字符一个都不能错 - 验证方式：在命令面板执行
Preferences: Open Settings (JSON)，手动输入"colorTheme": "xxx"后保存，看左下角是否立刻切换主题
多人共用同一套颜色配置时，最常踩的兼容性坑
不是颜色值错了，而是 token 类型在不同语言插件里映射不一致 —— 比如你给 "keyword" 设了红色，但 Python 插件没定义该 token，TypeScript 插件却把它当 "storage.modifier" 处理。
- 优先用语言中立的 token：如
"comments"、"strings"、"numbers"，它们在绝大多数语言插件中都有稳定映射 - 避免覆盖
"editor.foreground"或"editor.background"—— 这些属于 UI 层，会被主题本身覆盖，写进去等于白设 - 如果团队用不同语言栈，建议在
editor.tokenColorCustomizations下按语言分组，例如："[javascript]": { "keywords": "#cc7a8b" } - 注意 VSCode 版本差异：1.90+ 开始强化了 semantic token 优先级，老配置可能被新机制绕过，测试时务必用团队最低版本验证
真正难的不是写配置，而是让所有人意识到：颜色不是“个人喜好”，而是代码语义的延伸。一旦某人偷偷改了 editor.tokenColorCustomizations 里的 "functions" 颜色，又没同步进 .vscode/settings.json，那他写的函数调用，在别人眼里就和普通变量一样不可区分 —— 这种隐性认知偏差，比语法错误更难 debug。
