sublime text 默认不自动统一换行符，需配置 "default_line_ending": "unix" 实现新建文件默认 lf；但已存 crlf 文件需手动切换或借助 .gitattributes（eol=lf）由 git 统一规范。
Sublime Text 默认会根据文件已有的换行符自动检测并保持一致，但如果你打开一个 LF 文件却看到 ^M 符号、保存后 Git 提示大量换行符变更，或者协作时被队友抱怨“你改了所有行”，那基本就是换行符不统一惹的祸——这不是编码问题，是行尾（EOL）配置没对齐。
怎么查看当前文件用的是 CRLF 还是 LF
右下角状态栏会明确显示：CRLF 或 LF。点击它就能弹出切换菜单。这是最直接的方式，不用猜、不用查文件头。
如果状态栏没显示，说明 Sublime Text 没识别出 EOL —— 常见于新建空白文件或某些二进制混入的文本；此时默认行为是按系统来（Windows 用 CRLF，macOS/Linux 用 LF），但不会写入到文件中，直到你第一次保存。
- 新建文件未保存前，
LF/CRLF状态是灰色的，点不了 - 保存后立刻生效，且后续编辑都沿用该格式，除非手动切换
- Git 仓库里建议统一用
LF（哪怕在 Windows 上），避免 diff 泛滥
如何全局默认设为 LF（推荐团队协作）
靠每次点状态栏太慢，尤其开一堆文件时。直接改用户设置：
{
"default_line_ending": "lf"
}
这个设置只影响「新创建且未保存过的文件」以及「没有明确换行符的文件」；已有内容的文件仍保留原 EOL，不会强制转换。
-
"default_line_ending"可选值只有"system"、"unix"（即LF）、"windows"（即CRLF） - 别写
"lf"或"crlf"字符串——Sublime Text 不认，会退回到 system - 改完设置后，新开一个空标签页，右下角就该显示
LF了
怎么批量把 CRLF 转成 LF（慎用！）
别用「查找替换」去删 ^M——容易误伤、不可逆、还可能破坏文件编码。正确做法是用 Sublime Text 自带的转换功能：
- 菜单栏 → File → Line Endings → 选
Unix (LF) - 或快捷键：
Ctrl+Shift+P（Win/Linux）/Cmd+Shift+P（macOS），输入Set Line Ending to Unix - 操作后，右下角立刻变
LF，且光标所在行尾符号实时更新 - 注意：此操作仅修改内存中的视图，必须
Ctrl+S才真正写入磁盘
如果文件很大（比如 >10MB），转换过程可能卡顿几秒，但不会崩溃——Sublime Text 是逐行处理的，不是全载入再替换。
为什么 .gitattributes 比编辑器设置更可靠
靠每个成员改 Sublime 设置，不如让 Git 自己管换行符。在项目根目录加 .gitattributes：
* text=auto eol=lf *.bat text eol=crlf *.ps1 text eol=crlf
这样无论谁用什么编辑器、什么系统，Git checkout 时自动转 LF，commit 时也统一转 LF（除明确标注的 Windows 脚本）。
这个文件比编辑器设置优先级更高，而且能跨编辑器生效。Sublime Text 的 default_line_ending 只管“怎么新建”，而 .gitattributes 管“怎么存、怎么取”——后者才是源头治理。
最容易被忽略的一点：改完 .gitattributes 后，得重置 Git 缓存才能生效：git add --renormalize .，否则旧文件的换行符记录还在 index 里。
