新建文件默认换行符由"default_line_ending"配置决定：设为"unix"即lf，"windows"即crlf，"system"则依系统；它仅影响ctrl+n新建的空白文件，不改变已打开或加载的文件。
新建文件默认用 LF 还是 CRLF？看这个配置项
Sublime 新建文件的换行符不由当前打开的文件决定，也不随系统自动变——它只听 default_line_ending 这一个配置。Windows 上默认是 CRLF，但你完全可以强制它新建即用 LF，只要改对地方。
- 打开 Preferences → Settings – User，在右侧 JSON 中添加或修改：
"default_line_ending": "unix" - 值必须小写、严格匹配：
"unix"（LF）、"windows"（CRLF）、"system"（回退系统默认） - 改完保存，之后所有
Ctrl+N或菜单新建的空白文件，第一行结尾就是\n - 注意：已打开的文件、从磁盘加载的文件、拖进来的文件，完全不受影响
右下角显示 CRLF 却没反应？别急着改设置
状态栏显示 CRLF 或 LF 是当前文件的真实换行格式，点击它能立刻切换——但这只是单文件操作，和 default_line_ending 无关。很多人误以为“点了 LF 就一劳永逸”，结果新建文件还是 CRLF，其实是混淆了「当前文件」和「新文件模板」两个层级。
- 右下角显示
CRLF→ 当前文件确实含\r\n，点它可切到LF，保存即生效 - 新建文件仍为 CRLF → 说明
default_line_ending没设，或设成了"windows"或"system" - 如果项目里混用多种换行风格，光靠编辑器设置不够，还得配
.gitattributes，否则 Git 提交时可能偷偷转回 CRLF
为什么改了 default_line_ending 还是不生效？
常见失效不是因为写错，而是被更高优先级规则覆盖了。Sublime 的换行符控制有明确作用域层级，用户设置只是底层基础。
-
default_line_ending只管「新建空白文件」，不干预任何已有文件 - 如果装了 EditorConfig 插件，且项目根目录有
.editorconfig并含end_of_line = lf，它会覆盖default_line_ending - Git 的
core.autocrlf设置也会在读写文件时介入：比如设成true（Windows 默认），检出时自动转 CRLF，导致 Sublime 显示的是 CRLF，哪怕磁盘里存的是 LF - 验证是否真生效：新建一个文件（
Ctrl+N），立刻按Ctrl+S保存为test.txt，再用命令行查：file test.txt或xxd test.txt | head -1
跨平台协作时真正要盯住的边界不在编辑器里
编辑器设好 default_line_ending 只解决了一半问题。团队里有人用 Windows + Sublime，有人用 macOS + VS Code，Git 工作区和暂存区之间的换行符转换才是静默破坏者。
- 仅靠 Sublime 设置无法保证提交内容统一，必须配合 Git 配置：
git config --global core.eol lf和git config --global core.autocrlf input（Linux/macOS）或false（Windows） -
.gitattributes文件比编辑器配置更可靠：* text=auto eol=lf声明所有文本文件以 LF 结尾，Git 会据此规范工作区行为 - 如果已有历史提交混入 CRLF，
default_line_ending再正确也救不回旧文件——得用dos2unix批量清理，或让 CI 拒绝 CRLF 提交
换行符问题从来不是纯编辑器配置题，它是编辑器、Git、项目配置三者咬合的结果。漏掉任意一环，协作时就容易在右下角看到那个刺眼的 CRLF 提示。
