必须同时启用"draw_white_space":"all"和"show_line_endings":true，前者为换行符预留渲染位置，后者才真正触发¶(crlf)、↵(lf)或⌍(cr)符号显示。
怎么让每行末尾显示 ↵ 或 ¶ 符号
必须同时启用两个设置："draw_white_space": "all" 和 "show_line_endings": true。只开一个，换行符符号不会出现。
"draw_white_space": "all" 的作用是为所有空白字符（包括换行符）预留渲染位置——它让空格变·、Tab变→，但不决定换行符画不画；"show_line_endings": true 才是真正触发符号绘制的开关：LF 显示为 ↵，CRLF 显示为 ¶，CR 显示为 ⌍。
常见错误：
- 把
"draw_white_space"写成true或"on"—— 值必须是英文双引号包裹的字符串"all" - 在左侧 Default Settings 里改配置 —— 升级后会被覆盖，所有自定义必须写在右侧 User Settings 中
- JSON 格式出错，比如漏逗号、多逗号、用中文引号 —— 整段配置静默失效，行末符号和空格都看不到
为什么状态栏不显示 LF/CRLF
右下角那个 LF 或 CRLF 不是“默认显示”，它依赖 Sublime 对文件内容的实际解析，很多情况会主动隐藏或延迟显示。
优先排查这几项：
- 文件是新建未保存的
untitled—— 必须先Ctrl+S保存为真实路径，状态栏才开始识别 - 文件末尾缺换行符（
no newline at end of file）—— Sublime 推断不稳定；保存一次再重开常能触发识别 - 插件抢占状态栏右侧区域（如旧版 BracketHighlighter）—— 临时禁用插件验证是否冲突
- 编码异常（如 UTF-16、带 BOM 的混合编码）—— 换行符检测逻辑降级，状态栏直接隐藏该标识；建议先转成
UTF-8再试
切换换行符格式前要确认当前实际类型
菜单里的 File → Line Endings → Unix (LF) 是破坏性操作：保存时整份文件所有换行符会被统一替换，Git diff 会标红全部行。
Sublime 判断依据是文件中第一个有效换行符，不是扩展名，也不警告混合使用。别全信状态栏——快速验证原始字节更可靠：
- 命令行：
xxd -l 32 yourfile.txt | grep -o '\r\n\|\n' - Python：
open('f', 'rb').read()[:64]查看前 64 字节
如果只是想让新文件默认用 LF，加配置项："default_line_ending": "unix"；若需按项目区分（比如 Windows 工具链要求 CRLF），配合 .editorconfig 更稳妥。
为什么开了 "draw_white_space": "all" 还看不到 ¶
这是最常被误解的一点：这个设置本身并不负责绘制 ¶ / ↵ / ⌍，它只管空格和 Tab 的可视化。¶ 符号能否显示，完全取决于 "show_line_endings": true 是否生效。
另外注意：
- 即使两个设置都正确，如果文件编码或结构异常（如开头有非法 BOM、混用 CR/LF/CRLF），Sublime 可能跳过换行符渲染逻辑，只显示 · 和 →
- 某些语法高亮插件（尤其是自定义 scope 的）会干扰空白字符渲染，可临时切到
Plain Text语法验证 - 状态栏显示 LF 但行末没 ↵？说明
"show_line_endings"生效了，但"draw_white_space": "all"因 JSON 错误或位置不对没加载成功
换行符符号的显示是“双保险”机制，少一环就彻底不可见——这正是最容易被忽略的复杂点。
