convert line endings to lf命令需配合save all才能生效，否则仅内存修改；状态栏切换不写入磁盘；批量处理须先多选标签页再执行转换与保存两步；推荐用.gitattributes统一项目换行符。
Convert Line Endings to LF 命令能批量转换已打开文件的换行符，但不会自动保存——这是最常被忽略、导致“改了又变回来”的根本原因。
为什么右下角点 LF/CRLF 没用
状态栏点击 CRLF 或 LF 只是切换当前视图的显示格式，不写入磁盘。常见现象：点了 Convert to Unix line endings，右下角变 LF，关掉再打开又回 CRLF。
- 该操作仅影响当前文件，对其他已打开或未打开的文件完全无感
- 若文件是只读（右下角标
RO），菜单命令会静默失效，需先解除只读或用管理员权限重开 Sublime - Git 检出的文件在 Windows 上若启用了
core.autocrlf=true，即使你手动转成 LF 并保存，下次git checkout仍可能还原为 CRLF
真正批量处理多个已打开文件
这是 Sublime 原生最接近“批量”的方案，但必须分两步执行，缺一不可：
- 用
Ctrl+Click（Windows/Linux）或Cmd+Click（macOS）多选标签页，或先用Ctrl+P批量打开目标文件 - 按
Ctrl+Shift+P调出命令面板，输入Convert Line Endings to LF（注意大小写，不能全小写）并回车 - 再次调出命令面板，输入
Save All并回车——这步不可省，否则所有转换都只是内存里的临时状态 - 如需转为 CRLF，命令是
Convert Line Endings to Windows，不是to CRLF
用正则替换跨文件改换行符的风险
在 Find in Files（Ctrl+Shift+F）里搜 \r\n 替成 \n 看似直接，但极易出问题：
-
\r\n在 UTF-16 文件中会被解析为两个独立字符，替换后破坏字节对齐，文件可能损坏 - 混杂换行格式（如既有
\r\n又有\r\r\n）时，\r\n查找会漏掉脏数据，得先用\r{2,}\n清理 - 正则中的
\n在替换框中代表“换行符”，但实际写入时是否真变成 LF，取决于当前文件的line_ending设置，不是绝对可靠 - 更稳妥的做法：用
Find in Files定位所有目标路径，丢给终端命令处理，例如 macOS/Linux 下运行dos2unix ./src/**/*.js
项目级统一换行符别只靠 Sublime
靠 Sublime 手动开、转、存几百个文件，效率低、易遗漏，且无法防止新文件再出问题。关键点在于：
-
default_line_ending配置（在Preferences → Settings中设置）只对新建空白文件生效，不影响已有文件 - 文件自身的换行符类型优先级最高，打开即锁定；View 菜单里的选择是临时覆盖；配置项仅兜底
- 真正想统一整个代码仓库，应配合
.gitattributes（如* text=auto eol=lf）或构建脚本清洗，而不是依赖编辑器单点操作
真正容易被忽略的是：Sublime 不校验语法，也不感知上下文。改完之后，得靠人眼扫关键分隔处，或用 Ctrl+F 搜 \n\n 确认是否还有残留双空行——机器改得快，但“改对”这件事，还得人来把关。
