sublime text中右下角状态栏显示crlf或lf，未显示时可用命令面板“set line endings”查看或hexviewer查0d 0a（crlf）、0a（lf）；批量转换用“convert line endings to lf/crlf”命令，支持多标签；换行符由文件自身类型、view菜单、default_line_ending配置三级控制，旧文件保存仍保持原换行符；跨平台需注意shell脚本、python路径、git diff及构建输出中的换行符问题。
怎么判断当前文件用的是 CRLF 还是 LF
打开文件后，右下角状态栏会显示换行符类型，比如 CRLF 或 LF。如果没显示，说明 Sublime Text 没识别出差异（常见于空文件或纯 ASCII 内容），这时可以手动检查：用 Ctrl+Shift+P（Windows/Linux）或 Cmd+Shift+P（macOS）调出命令面板，输入 Set Line Endings，看当前选中项；或者用十六进制编辑器插件（如 HexViewer）查末尾字节：0D 0A 是 CRLF，0A 是 LF。
如何批量把 CRLF 改成 LF（或反过来）
最稳的方式不是靠保存时自动转换，而是显式执行转换操作：
- 打开文件 →
Ctrl+Shift+P→ 输入Convert Line Endings to LF（或to CRLF）→ 回车 - 支持多标签同时操作：先
Ctrl+Click点击多个标签页，再执行上述命令 - 注意：这个操作不改变文件编码，只动换行符；如果文件里混有
\r\r\n这类脏数据，会原样保留，得先用正则\r{2,}\n清理 - 命令名区分大小写，别输成
convert line endings—— Sublime 默认只匹配首字母大写的完整命令
为什么改了设置还是保存为 CRLF
Sublime Text 的换行符行为由三处控制，优先级从高到低：
- 文件自身已有换行符类型（打开即锁定，除非手动转换）
-
View → Line Endings菜单里的当前选择（临时覆盖） -
Preferences → Settings里的"default_line_ending"配置（仅对新建空白文件生效）
所以如果你改了 default_line_ending 为 "lf"，但打开一个旧的 CRLF 文件再保存，它依然会保持 CRLF —— 这不是 bug，是设计。真正想“统一项目换行”，得配合 Git 的 .gitattributes 或用 sed -i 's/\r$//' * 批量清洗。
跨平台协作时哪些场景必须留意换行符
不是所有地方都敏感，但这几个点容易翻车：
- Shell 脚本（
.sh）在 Linux/macOS 上遇到CRLF会报错/bin/bash^M: bad interpreter—— 因为^M（即\r）被当成了命令名的一部分 - Python 的
__file__路径在 Windows 上带CRLF可能导致import失败（极少见，但发生在某些打包工具里） - Git 提交时若没配
core.autocrlf，同一行代码在不同系统上 diff 显示“内容变了”，其实是换行符在捣鬼 - Sublime 的
build system输出如果含CRLF，某些终端模拟器（如 VS Code 内置终端）可能多出空行
换行符问题从来不是编辑器单方面的事，它卡在编辑、提交、执行三个环节之间。盯着 Sublime 设置调，不如先确认 Git 和目标运行环境要什么。
