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 中添加或修改这一行：

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

{
    "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 的工作区和暂存区之间。