editorconfig 插件在 sublime text 中需满足四条件才生效：1. 文件名为.editorconfig且置于项目根目录；2. 必含root = true；3. 关闭sublime的detect_indentation；4. 确保editorconfig-core-py可用且语言插件未覆盖设置。
EditorConfig 插件在 Sublime Text 中不是“锦上添花”，而是多人协作时避免格式冲突的底线工具——但装了不等于生效，配置错一行就白搭。
EditorConfig 插件为什么没反应？检查这四件事
常见现象：indent_style = space 写了，但按 Tab 还是插 Tab 字符；end_of_line = lf 设了，保存后 Git 仍报 CRLF 修改。根本原因不是插件坏了，而是加载链断了。
- 文件名必须严格为
.editorconfig（开头带点、全小写、无后缀），放在你用 Sublime 打开的**项目根目录**下；子目录或.editorconfig.txt都无效 -
root = true必须存在且位于文件顶部附近——没有它，Sublime 会继续向上找父目录的.editorconfig，可能意外加载到别的项目配置 - 关闭 Sublime 自身干扰项：在
Preferences.sublime-settings中显式设"detect_indentation": false，否则它会“记住”旧文件的缩进并优先使用 - 确认插件依赖的
editorconfig-core-py命令行工具已全局可用（尤其 macOS M1/M2 或 Windows WSL 用户），否则插件静默降级为不工作
缩进和换行规则只影响“新行为”，不重写已有内容
这是最常被误解的一点：EditorConfig 不是格式化器，它只控制编辑器后续输入、粘贴、重排版（如 Ctrl+Shift+P → Reindent）时的行为，不会自动把文件里已有的 4 个空格转成 Tab，也不会在打开时批量改换行符。
-
indent_size = 2+indent_style = space只保证你按 Tab 键时插入 2 个空格，不影响已有行的缩进字符 -
end_of_line = lf仅在**保存时**生效，且前提是文件当前编码支持转换（GBK 编码下强行设lf会被跳过） - 想批量修正历史文件？得用外部工具，比如
dos2unix或autopep8 --in-place --aggressive，EditorConfig 不负责这事
语言专属插件可能覆盖 EditorConfig 设置
比如 JS Custom、Anaconda、Vue Syntax Highlighter 这类语言增强插件，常自带缩进推断逻辑。一旦它们启用 infer_indent 或硬编码 tab_size，就会绕过 .editorconfig 的声明。
- 查对应插件的设置文件（如
JS Custom.sublime-settings），关掉"infer_indent": true这类选项 - 确保 Sublime 全局设置里没写死
"tab_size": 4或"translate_tabs_to_spaces": true—— 这些会和.editorconfig冲突，且优先级不一定高 - 多根工作区下，每个根目录都要有独立的
.editorconfig；Sublime 不跨根目录合并规则
团队落地时最容易被忽略的细节
真正卡住团队的，往往不是语法写错，而是环境链路断在看不见的地方：Windows 成员用记事本编辑 .editorconfig，保存成 CRLF 换行，导致 Sublime 插件直接拒绝加载该文件（规范要求配置文件本身必须用 LF）；又或者 CI 流水线没跑 editorconfig-checker，结果大家以为一致，实际提交的文件早已偏离约定。
别只盯着文件内容——检查换行符、确认 CLI 工具路径、禁用编辑器自身推断、让 CI 做最终仲裁，这些才是 EditorConfig 在 Sublime 里稳住团队代码风格的关键支点。
