需同时启用 "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 失败或脚本报错。
一款AI工具,主要用于将PREQSTATION编码任务委派给Claude Code、Codex CLI或Gemini CLI,采用PTY安全执行(工作目录+后台+监控),适合需要提升相关任务效率的用户。
- 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 显示清楚也没用。










