必须设 draw_white_space: "all" 才能稳定显示 · 和 →，其他值或开关操作均不可靠；需同时关闭 translate_tabs_to_spaces 以显示 →，并额外启用 show_line_endings 显示 ¶。
必须设 draw_white_space: "all" 才能稳定显示 · 和 →
其他值或开关操作都不可靠："none" 什么也不显，"selection" 只在选中时闪一下，容易漏掉缩进错位；菜单里的【View → Show Hidden Characters】行为不稳定，常只显示 → 和 ¶，却不画空格 ·。唯一确定生效的方式是手动编辑用户设置，加这一行：{"draw_white_space":"all"}。注意引号必须是英文双引号，值必须是字符串 "all"，写成 true、on 或漏引号都会导致整段 JSON 解析失败，且 Sublime 不报错——它就默默忽略你改的这行。
translate_tabs_to_spaces 关了才能看到 →
即使 draw_white_space 设对了，如果 translate_tabs_to_spaces 是 true（很多 Python 项目默认开启），那按 Tab 插入的全是空格，文件里根本没有 \t 字符，自然不会渲染 →，只会满屏 ·。此时右下角状态栏会显示类似 Tab Width: 4 (Spaces)。要确认原始缩进结构，得临时关掉它："translate_tabs_to_spaces": false，再重新打开文件或粘贴含真实 \t 的文本。但别忘了团队协作前统一风格，否则 Git diff 里会出现一堆 ^I。
show_line_endings 是独立开关，控制 ¶ 显示
draw_white_space 管不到换行符。想让每行末尾出现段落符号 ¶，必须额外加 "show_line_endings": true。它和 draw_white_space 完全解耦：开了 draw_white_space 但没开这个，就看不到 ¶；开了这个但 draw_white_space 是 "none"，就只看到 ¶，没有 · 或 →。跨平台协作时（比如 Windows 提交 LF/CRLF 混用），¶ 比 · 更关键，因为它直接对应 Git 警告里的换行符类型。
临时查看别动配置：用 Toggle White Space 命令
代码审查中途想快速确认某几行有没有混用缩进？不用改用户设置。按 Ctrl+Shift+P（Win/Linux）或 Cmd+Shift+P（macOS），输入 Toggle White Space 回车——它瞬间在 "all" 和 "none" 之间切换，当前会话有效，关掉 Sublime 就恢复原状。注意两点：它不启用 show_line_endings，所以 ¶ 不会出现；它也不是菜单里的【Show Hidden Characters】，后者逻辑陈旧，有时漏渲染。
真正难的不是让 · 和 → 出来，而是看到它们之后，立刻分辨出哪一行该留 Tab、哪一段该转空格、哪个行尾空格其实是隐藏的格式污染——这时候状态栏的 Tab Width、CR/LF 和右下角语法标识，比显示本身还重要。
