Sublime Text在Windows上新建文件默认用CRLF，因default_line_ending全局配置默认为"system"；改为"unix"可强制新建文件使用LF，但不影响已打开文件，跨平台还需Git和.gitattributes协同规范换行符。
为什么新建文件默认是 Windows 换行符？
Sublime Text 在 Windows 系统上默认使用 CRLF（\r\n），这是系统级行为，不是用户误操作导致的。即使你手动把当前文件换行符改成 LF（\n），下次新建文件仍会回到 CRLF——因为新建文件不继承当前文件的换行设置，而是读取全局默认值。
修改 default_line_ending 配置项
这个配置项控制所有新建文件的换行符类型，必须写在用户设置中，且值区分大小写：
-
"default_line_ending": "unix"→ 强制新建文件用LF -
"default_line_ending": "windows"→ 用CRLF -
"default_line_ending": "system"→ 回退到系统默认（Windows 下就是CRLF）
打开菜单：Preferences → Settings – User，在右侧 JSON 中添加或修改这一行：
{
"default_line_ending": "unix"
}
注意：该设置不影响已打开的旧文件
它只对「新建空白文件」（Ctrl+N 或菜单 File → New File）生效。已存在的文件、从磁盘打开的文件、通过拖拽/双击打开的文件，其换行符保持原样，不会被自动转换。
- 要批量修复已有文件，需手动执行
File → Line Endings → Unix (LF) - 插件如
EditorConfig可按项目覆盖此设置，但前提是项目根目录有.editorconfig文件并包含end_of_line = lf - 如果同时启用了 Git，建议同步配置
core.autocrlf = false或core.eol = lf，否则 Git 可能悄悄改换行符，造成 Sublime 显示与磁盘实际不一致
跨平台协作时真正容易被忽略的一点
仅设 default_line_ending 不够。团队里有人用 Windows + Sublime，有人用 macOS + VS Code，还得靠 .gitattributes 统一规范：
* text=auto eol=lf *.py text eol=lf *.md text eol=lf
否则，哪怕 Sublime 新建全是 LF，Git 提交时仍可能因本地 autocrlf 设置不同而引入 CRLF，别人拉下来就看到换行符警告。这个边界不在编辑器里，而在 Git 的工作区和暂存区之间。
