sublime构建系统文件必须存放在packages/user/目录下，通过tools→build system→new build system…创建并保存为.sublime-build格式；其他路径均无效，且需确保json合法、selector匹配、cmd为数组、windows路径加引号和双反斜杠。
Sublime构建系统文件在哪？
自定义构建系统是纯文本 .sublime-build 文件，存放在 Packages/User/ 目录下。它不会自动创建——只有你通过 Tools → Build System → New Build System… 打开编辑器并保存后，才会生成一个默认的 untitled.sublime-build（你得手动改名，比如 python3.sublime-build）。
别去 Installed Packages/ 或 Default Packages/ 翻找，那些是只读系统级构建系统，改了也没用，升级还会被覆盖。
导出时只复制 .sublime-build 文件够不够？
单独拷 myproject.sublime-build 能还原构建命令，但实际迁移后常出现「按 Ctrl+B 没反应」或「报错 Unable to find build system」——问题往往不在 build 文件本身，而在隐式依赖：
-
Packages/User/Preferences.sublime-settings里可能设置了"fallback_encoding"或"default_encoding"，影响 Python 脚本读取中文路径 - 如果构建命令调用了插件提供的命令（比如
emerald插件的run_in_terminal），那Packages/Emerald/目录也得一并备份，否则命令找不到 - 某些构建系统依赖外部工具路径（如
node、go），这些路径写死在cmd字段里，换机器前得改成相对路径或环境变量引用（如"cmd": ["${env:PATH}/node", "$file"]）
如何让构建系统跨机器稳定生效？
关键不是“导出”，而是“解耦路径与环境”。直接写死 "cmd": ["C:\Python39\python.exe", "$file"] 或 "/usr/local/bin/python3" 是最常见失效原因。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
推荐做法：
- 用
${env:PATH}、${packages}、${file_path}这类内置变量替代绝对路径 - 把工具路径交给系统管理：确保新机器上
python3、npm已加入$PATH，然后构建系统里只写["python3", "$file"] - 若必须指定解释器，优先用软链接方式统一入口（如 macOS/Linux 下
ln -s /opt/homebrew/bin/python3 /usr/local/bin/python3） - 构建系统中避免硬编码项目路径；路径相关逻辑应由
$file、$file_path、$project_path动态带入
备份时要不要关掉 Sublime？
要。Sublime 在运行时会热重载 Packages/User/ 下的 .sublime-build 文件——你一边复制，它一边写入临时缓存，可能导致文件损坏或内容不全。
操作前务必：
- 执行 File → Exit（Windows/Linux）或 Sublime Text → Quit Sublime Text（macOS）
- 检查任务管理器 / 活动监视器，确认没有残留的
subl或sublime_text进程 - 再进入
Packages/User/复制所有*.sublime-build文件（包括你改过但没保存的临时文件，它们可能以untitled X.sublime-build形式存在）
真正容易被忽略的是：构建系统文件本身没问题，但它的执行上下文（PATH、当前工作目录、插件可用性）才是跨机器后失效的主因。备份只是起点，验证必须在目标机器上用真实文件触发一次 Ctrl+B 并观察控制台输出。
