Sublime Text换行符管理：三层逻辑与实战指南
在Sublime Text里统一换行符格式，可不是一个简单的全局设置就能搞定的事。它背后其实有一套三层逻辑在运作：当前文件的真实格式、新建文件的默认值，以及项目级的覆盖规则。如果没搞清楚这三者的关系，很可能改了半天却发现根本没生效。
第一步：确认当前文件的真实格式
最直接的方法，就是看一眼编辑器右下角的状态栏。如果显示着LF或CRLF，那这就是文件当前真实的换行符类型。但有时候，这里什么也不显示——这通常发生在空文件，或者文件行末没有明确换行符的情况下。这时候别猜，有两个更可靠的办法：
- 按下
Ctrl+Shift+P调出命令面板，输入Set Line Endings，高亮显示的选项就是当前文件的格式。 - 安装
HexViewer插件，直接查看文件末尾的字节：0A对应LF，0D 0A则对应CRLF。
第二步：快速转换单个文件的格式
如果确认了格式需要转换，操作其实很简单。直接点击右下角的LF或CRLF标识，在弹出的菜单中选择Convert to Unix line endings（转为LF）或Convert to Windows line endings（转为CRLF）。这个操作非常纯粹，只改变换行符，不会影响文件编码或文本排版。
不过，这里有三个关键点必须注意：
- 必须手动保存：转换后，务必按
Ctrl+S保存文件，更改才会写入磁盘。不保存就等于白忙活。 - 注意“脏数据”：如果文件里混杂了类似
\r\r\n这样的异常字符，这个转换功能会原样保留它们。最好先用正则表达式（如\r{2,}\n）清理一下。 - 命令名要写对：在命令面板里操作时，
Convert Line Endings to LF这样的完整名称是有效的，而简写或大小写错误可能无法匹配。
第三步：设置新建文件的默认格式
想让以后新建的文件都默认使用Unix风格的LF换行符？这就需要修改用户设置了。打开Preferences → Settings – User，在右侧的JSON配置区域里，添加这样一行：
"default_line_ending": "unix"
这里的值必须小写且严格匹配："unix"代表LF，"windows"代表CRLF，"system"则使用系统默认值。
但别以为这就一劳永逸了，这个设置有两个重要的限制：
- 它只对通过
Ctrl+N新建的空白文件生效，对于已经打开或者从外部拖入的文件，它无能为力。 - 如果项目中使用了
EditorConfig插件，并且根目录下有.editorconfig文件，其中定义了end_of_line = lf，那么这个项目级规则会直接覆盖用户的default_line_ending设置。改完配置发现新建文件还是CRLF？大概率就是被.editorconfig或者某个文件模板“劫持”了。
第四步：批量转换的实战方案
Sublime Text本身并没有提供“选中一堆文件直接转换”的图形化功能，但我们可以通过组合操作高效完成：
- 首先，用
Ctrl+Click在标签栏上多选需要转换的文件，或者用Ctrl+P快速打开多个目标文件。 - 接着，
Ctrl+Shift+P调出命令面板，输入Convert Line Endings to LF并回车。 - 此时，所有已打开文件的换行符都会被修改，但记住，这还只是在内存中。最后，必须再执行一次
Ctrl+Shift+P→Sa ve All，才能真正将更改全部保存到磁盘。
话说回来，如果要处理的是整个目录（比如src/文件夹下的所有.py文件），其实不建议完全依赖Sublime Text。对于这种批量任务，使用系统级工具往往更稳定、更快速：
- 在macOS或Linux上，直接用
dos2unix命令。 - 在Windows上，可以使用PowerShell的
Set-Content -Encoding UTF8NoBOM。
最后，必须强调一个核心观点：在跨平台协作的开发环境中，换行符问题的终极防线其实不在编辑器里，而在版本控制工具Git的配置里。无论是.gitattributes文件的规则，还是core.autocrlf的全局设置，才是确保代码在Windows、macOS和Linux之间穿梭而不出乱子的底层保障。编辑器层面的转换，很多时候只是解决了表面问题，静默的数据破坏往往发生在代码的检出和提交环节。理解了这一点，才算真正掌握了换行符管理的精髓。
