Sublime 通过右下角状态栏显示当前文件换行符类型（LF 或 CRLF），而非靠 draw_white_space；若未显示，说明文件换行符统一且无异常，或末尾缺换行符、编码不兼容。
怎么让 Sublime 显示行尾是 LF 还是 CRLF？ Sublime 默认不显示换行符类型，得手动打开「行尾显示」功能。这不是靠插件，而是内置的 `draw_white_space` 设置控制的——但要注意，它只显示空格/制表符，**不直接标出 LF 或 CRLF**；真正能区分换行符类型的，是右下角的状态栏和「File → Line Endings」菜单。
实操建议：
- 点击窗口右下角（通常显示
UTF-8、Python那块），看到CRLF或LF就是当前文件的实际换行符类型 - 想强制切换：菜单栏
File → Line Endings → Windows (CRLF)或Unix (LF) - 如果右下角没显示，说明 Sublime 没识别出换行符差异（比如全文件混用或为空行结尾缺失）
为什么有时右下角不显示 LF/CRLF？
常见错误现象：新建文件、粘贴内容后、或从 Git 拉取的文件，右下角只显示编码（如 UTF-8），不显示换行符类型。
原因很实际：
- 文件里所有行都用同一种换行符，且 Sublime 在加载时没检测到“混合”或“异常”，就默认隐藏该状态项
- 文件末尾没换行符（no newline at end of file），Sublime 可能无法稳定推断行尾类型
- 某些编码格式（如
UTF-16）下，行尾识别逻辑会降级，状态栏主动隐藏
如何让 Sublime 强制显示并统一换行符？ 单纯“显示”不够，很多场景（比如协作开发、CI 构建失败）需要确保 LF/CRLF 一致。Sublime 提供了配置项和命令双路径。
关键操作：
- 全局统一：在
Preferences → Settings里添加"default_line_ending": "unix"（或"windows"），新文件自动用该类型 - 当前文件转换：菜单
File → Line Endings → Convert to Unix (LF)，会重写所有行尾，**但不会改文件编码或内容逻辑** - 注意：Convert 是破坏性操作——一旦保存，原换行符就没了，Git diff 会显示整文件变更（尤其 Windows 用户切 LF 后）
LF/CRLF 混用会引发什么问题？ 不是纯视觉问题。真实协作中，LF/CRLF 错位会导致：
典型影响：
- Git 提交时触发
LF will be replaced by CRLF警告，甚至自动转换（取决于core.autocrlf设置） - Shell 脚本（
.sh）在 Windows 上用 CRLF 保存，bash 直接报错$'\r': command not found - Python 的
open(..., newline='')行为在不同平台对换行符敏感，读取结果可能多出\r - Sublime 自身的多光标编辑、正则替换（如
\n）在 CRLF 文件里可能漏匹配，因为实际是\r\n
LF 或 CRLF 不只是状态提示，它是文件被解释方式的开关。很多人改完设置发现没变化，是因为没意识到：Sublime 只在**有依据时才显示它**，而依据来自文件字节本身——不是配置，也不是预设。 
