EditorConfig 生成器

.editorconfig 有什么用

项目根目录下名为 .editorconfig 的文件用来声明格式约定。支持 EditorConfig 的编辑器（所有主流 IDE 和大多数现代文本编辑器）会在打开文件时套用这些规则。查找过程从正在编辑的那个文件出发，沿目录树逐级向上，遇到第一个写着 root = true 的文件就停下。

输出示例

用默认设置（空格、缩进宽度 4、LF、utf-8），加上已经替你勾好的两个区块，生成器输出：

root = true

[*]
indent_style = space
indent_size = 4
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
max_line_length = 120

[*.{md,markdown}]
trim_trailing_whitespace = false

[{Makefile,makefile,GNUmakefile,*.mk}]
indent_style = tab

再勾上 Python、Go 或 YAML，对应的区块就会出现在下面，并且已经带好了该技术栈的格式化工具所强制的约定。

主要指令

三条会让构建失败的规则，它们不只是风格偏好

.editorconfig 里的大多数条目只是偏好。下面这三条不是，它们正是值得为每种语言单独写一个区块的理由：

• YAML 禁止用制表符缩进。 这是解析错误，不是 lint 警告。如果你的项目用制表符缩进，同时又有 GitHub Actions 工作流、Docker Compose 文件或 Kubernetes 清单，那么 YAML 区块就必须把空格强制改回来。
• make 要求每条规则的命令行以真正的制表符开头。 用空格会得到 missing separator. Stop.，构建就此中止。这也是 [{Makefile,makefile,GNUmakefile,*.mk}] 列出好几种写法的原因：EditorConfig 匹配文件名时区分大小写，而仓库里 Makefile 和 makefile 两种写法都有人用。
• 用 CRLF 保存的 Shell 脚本根本不会运行。 内核会把回车符当成解释器路径的一部分，然后报出类似 /bin/bash^M: bad interpreter: No such file or directory 的错误。Windows 批处理文件则有个反过来的毛病：cmd.exe 是按字节偏移量去找 goto 和 call :label 的，所以只用 LF 保存的 .bat 可能跳到错误的行，或者中途停下却连个报错都没有。

这三条里有两条，全局区块非但修不好，反而正是祸根，所以这个生成器会专门盯着它们。如果你选了制表符却没有勾上 YAML 区块，或者选了 CRLF 却没有勾上 Shell 区块，那么它写出的文件哪怕一次都没提到那些文件，照样会把它们弄坏。生成器会在输出上方直接讲明白，而不是等你从一次失败的流水线构建里才发现。utf-16 那两个字符集也一样：它们会作用于项目里的每一个文件，而 make、Shell 解释器和 Python 都读不了这样保存的源码。

生成器会写入的各语言约定

请留意这张表里没有的东西：行长。PEP 8 说 79，Black 说 88，PSR-12 给的是不强制的 120，rustfmt 则是 100。把其中任何一个写进语言区块，都会悄悄盖掉你为整个项目选定的上限，所以生成器只把 max_line_length 留在 [*] 区块里，而把这些数字放在这里，由你自己决定要不要采用。

你的编辑器支持它吗？

原生支持的有：VS Code、JetBrains 的 IntelliJ 系列、Visual Studio、Sublime Text、Xcode 和 Notepad++。Vim、Emacs、Neovim 以及另外一些编辑器需要装一个小插件。这个文件就是普通的 INI 格式，代码检查工具和格式化工具同样读得懂，Prettier 和一些语言服务器正是这样跟它保持一致的。