Sublime Text需靠EditorConfig统一基础规则、语言专属格式化器（如prettier/autopep8）处理语法细节；须正确安装插件、配置路径、启用保存钩子、使用项目级配置文件，并确保格式化可逆且经团队评审。
怎么让 Sublime Text 自动按团队规范格式化代码
靠手动调格式不现实，Sublime 本身不带完整格式化引擎，得靠插件补足。核心是用 EditorConfig 统一基础规则（缩进、换行符），再用语言专属格式化器（如 prettier、autopep8）处理语法细节。
常见错误：只装 SublimeCodeIntel 或 SublimeLinter 就以为能格式化——它们只检查、不修正；或者把 .editorconfig 放错位置（必须在项目根目录，且父目录不能有同名文件干扰）。
-
EditorConfig插件需手动安装，并确保editorconfig-core-py命令行工具已全局可用（否则插件静默失效） - JavaScript/TypeScript 推荐绑定
prettier，但注意prettierv3+ 默认禁用--write的 CLI 输入流支持，需降级或改用prettierd - Python 用
autopep8时，--in-place参数必须开启，否则保存后无变化
为什么保存时没触发格式化，明明插件都装了
Sublime 默认不监听保存事件自动格式化，得手动配置键位或启用保存钩子。最稳的方式是关掉所有“格式化插件自带的保存即格式”开关，统一走 Sublime Text 原生的 on_save 事件 + exec 命令调用外部工具。
典型现象：JsPrettier 设置里勾了 “Auto format on save”，但保存后毫无反应——大概率是 Node.js 环境没被 Sublime 正确识别（尤其 macOS M1/M2 上通过 homebrew 装的 Node，路径常不在 /usr/bin）。
- 检查
Preferences → Package Settings → JsPrettier → Settings中"node_path"是否指向真实路径（比如"/opt/homebrew/bin/node"） - Python 类项目建议直接用
SublimeJEDI+autopep8组合，避免Black因依赖python3解释器路径不稳定导致失败 - 所有格式化命令必须设
"save_before": true，否则可能读到未保存的脏缓冲区内容
团队共用配置怎么避免本地覆盖
关键不是把配置塞进 Sublime 的 User 目录，而是把规则沉到项目里。Sublime 会逐级向上查找 .editorconfig 和语言专属配置文件（如 .prettierrc、.pycodestyle），优先级高于用户全局设置。
容易踩的坑：有人把 .prettierrc 写成 JSON 格式却加了注释，导致 prettier 启动失败，Sublime 日志里只报 "command not found"，实际是解析错误。
-
.editorconfig必须用LF换行，Windows 用户用记事本保存会变CRLF，导致插件跳过该文件 -
.prettierrc推荐用 YAML 格式（.prettierrc.yml），比 JSON 更容错，也方便加注释 - 禁止在
Preferences.sublime-settings里硬编码缩进值，否则新人 clone 项目后仍用 4 空格写 Python
格式化后代码跑不起来，是不是插件搞坏了
绝大多数时候不是插件“改坏”了代码，而是它暴露了原有隐患：比如 autopep8 把 if x: y() 拆成多行后，因缩进错误引发 IndentationError；或 prettier 重排 JSX 属性顺序，意外触发 React.memo 浅比较失效。
真实风险点在于：格式化器无法理解业务逻辑边界。例如把一行长 SQL 字符串拆成多行，中间不小心加了换行符，执行时报语法错误。
- 对 SQL、正则、模板字符串等敏感内容，加
// prettier-ignore注释临时跳过 - Python 中
from __future__ import必须在文件顶部，autopep8可能把它挪到 import 分组里，需在配置中设"aggressive": 0 - 所有格式化操作必须可逆——团队应约定：提交前跑一遍
git diff --cached，确认只有风格变更，没有逻辑改动
真正难的不是让 Sublime 执行格式化，是让所有人接受：格式化配置文件本身就是代码，要 review、要测试、要随业务演进。漏掉这点，工具越自动，问题越隐蔽。
