需同时启用 "draw_white_space": "all" 和 "show_line_endings": true 两项设置，前者预留渲染位置，后者实际显示 ¶/↵ 等符号。
怎么让 Sublime 在编辑器里直接看到 \n 或 \r\n 符号
Sublime 本身不渲染换行符为可见字符（比如 ¶ 或 ↵）除非你明确开启两个设置：一个是画出所有空白符，另一个是启用行尾符号绘制。只开一个没用——很多人试了 "draw_white_space": "all" 却没看到换行符，就是漏了后者。
-
"draw_white_space": "all"：让空格显示为·、Tab 显示为→，同时**也为换行符留出渲染位置**；但它本身不决定换行符画不画 -
"show_line_endings": true：这才是真正触发¶（CRLF）、↵（LF）或⌍（CR）符号显示的开关 - 两者必须同时存在，且写在用户设置（Preferences → Settings 右侧）中，格式要严格：
{ "draw_white_space": "all", "show_line_endings": true } - 注意：
"draw_white_space": true是无效写法；"all"必须是字符串，且英文双引号不能少
右下角状态栏不显示 LF/CRLF？先排查这四件事
状态栏那个小小的 LF 或 CRLF 是最准的当前文件换行符标识，但它不是永远都出现——它依赖 Sublime 对文件内容的实际解析结果，不是“默认显示”。
- 新创建未保存的
untitled文件不会显示，必须先Ctrl+S保存成真实路径 - 文件末尾缺换行符（no newline at end of file）时，Sublime 可能无法稳定推断，保存一次再重开常能触发识别
- 某些插件（如旧版 BracketHighlighter）会抢占状态栏右侧区域，临时禁用插件可验证是否冲突
- 编码异常（比如 UTF-16、带 BOM 的混合编码）会让换行符检测逻辑降级，状态栏主动隐藏该标识——此时建议先转成 UTF-8 再试
切换换行符别乱点「Convert」，先看清楚文件实际用了哪种
菜单里 File → Line Endings → Unix (LF) 看似简单，但它是破坏性操作：一旦保存，整份文件的换行符会被统一替换，Git diff 会标红全部行——尤其 Windows 用户切到 LF 后，协作时容易引发 CI 失败或脚本报错。
- Sublime 判断依据是**文件中第一个有效换行符**，不是扩展名也不是系统默认值；混合使用
\n和\r\n时，它只认第一个，也不警告 - 真正需要确认时，别全信状态栏——用命令行快速验证：
xxd -l 32 yourfile.txt | grep -o '\r\n\|\n'，或 Python 中open('f', 'rb').read()[:64]看原始字节 - 如果只是想让新文件默认用 LF，加配置项：
"default_line_ending": "unix"；若需按项目区分（比如 Windows 工具链要求 CRLF），配合.editorconfig更稳妥
为什么开了 draw_white_space 还看不到 ¶？和主题、字体、缩进设置都有关
即使配置全对，¶ 符号也可能隐形——不是功能失效，而是渲染被压制了。
- 当前配色方案（color scheme）可能把
¶设成和背景同色，换深色主题（如 Monokai）或调大font_size常能解决 - 如果启用了
"translate_tabs_to_spaces": true，文件里实际没有\t字符，那→就不会出现；但换行符符号¶不受此影响 -
"draw_indent_guides": true和换行符显示无关，别误以为开了它就能看到¶ - 大文件（>10MB）开启
"draw_white_space": "all"可能卡顿，这不是 bug，是 Sublime 实时渲染所有空白符的代价
换行符问题从来不在“怎么显示”，而在于“它到底是什么、谁在改它、改了之后谁会受影响”。Git 的 core.autocrlf、编辑器自动补行、.editorconfig 规则、CI 环境的 shell 解释器……这些地方任何一个没对齐，光靠 Sublime 显示清楚也没用。
