必须改用户配置里的"draw_white_space":"all"，这是唯一稳定生效的方案

想让Sublime Text老老实实把空格和制表符都显示出来？秘诀只有一个：在用户配置文件里，把 draw_white_space 的值设为 "all"。 其他那些方法，比如去菜单里勾选，要么是临时工，要么只显示一半——都不够靠谱。

为什么菜单里的「Show Hidden Characters」不推荐

这里有个常见的误区。很多人以为点一下「View → Show Hidden Characters」就万事大吉了。其实，这个菜单项只是在 "all" 和 "none" 之间做个临时切换，效果不保存，关了编辑器再打开就恢复原样。更麻烦的是，它在某些版本或主题下甚至会直接“隐身”，根本找不到。

• 它管不了换行符（就是那个 ¶），勾上了也看不见。
• 它没法清晰区分空格（·）和制表符（→）的显示逻辑，全凭编辑器自己猜。
• 团队协作时最头疼：你这边看着对齐了，别人没开这个选项，看到的可能完全是另一番景象。

draw_white_space 的三个合法值怎么选

这个配置项有点“挑食”，只认字符串，不认布尔值。你要是写成 true、on 或者忘了加引号，整个用户配置都可能解析失败，设置也就静悄悄地失效了。

• "none"：默认状态，一片“净土”，什么空白字符都不显示，缩进全凭感觉。
• "selection"：只在被选中的文本区域里显示 · 和 →。这容易漏掉行首的缩进、空行，或者注释后面的尾随空格。
• "all"：这才是“完全体”。它能持续显示所有空格、制表符、行尾空白。不过要注意，想看到换行符 ¶，还得额外配置 show_line_endings。

显示出来了，但 → 错位或 · 看不清怎么办

符号是显示了，但看起来不对劲？这通常受两方面影响：一是你用的配色方案（color scheme）给这些符号定义的颜色太淡或透明度太高；二是字体本身对这类Unicode符号的支持度不够。

• 先检查 translate_tabs_to_spaces 是不是 false。如果它是 true，编辑器会把制表符自动转成空格，文件里根本没有 \t，自然也就不会显示 →。
• 右下角状态栏显示的 Tab Width: 4 或 Spaces: 2，只是Sublime当前识别的缩进风格提示，不影响 → 符号的渲染。
• 如果 → 看起来模糊或者位置奇怪，大概率是遇到了“混合缩进”：某行用了4个空格，另一行却用1个制表符（假设Tab宽度是4）。视觉上好像对齐了，但字符本质不同。这时候，用命令面板（Ctrl+Shift+P）执行 Convert Indentation to Spaces 才是治本的办法。
• 临时排查的话，可以用 Ctrl+Shift+P 输入 Toggle White Space。这个命令不修改配置，只在运行时覆盖显示状态，特别适合Code Review时快速对比。

大文件卡顿、复制粘贴出错这些副作用怎么防

开启 "draw_white_space": "all" 后，编辑器需要实时扫描并绘制每一处空白字符。对于超过10MB的大文件，比如日志或者压缩过的JS代码，可能会感觉到明显的滚动迟滞和输入卡顿。

• 别以为在配置里加一行 "draw_white_space": "all" 就一劳永逸了。最好搭配 trim_trailing_whitespace_on_sa ve（保存时修剪尾随空格）和 detect_indentation（检测缩进）一起使用，减少后续的手动调整。
• 复制代码时要小心。尽量避免用鼠标拖拽选择，因为很容易意外选中行尾那些代表空格的 ·。使用 Ctrl+L（选择整行）或 Ctrl+Shift+↑/↓（扩展选择多行）会更安全。
• 把代码粘贴到Python、JSON或Makefile这类对缩进敏感的环境前，务必检查开头是不是Tab（→）。它看起来是缩进，但在Python里，一个不该出现的 \t 就可能引发语法错误。
• 最后，提交Git前也别完全相信Sublime的显示。混合使用 \t 和空格的文件，在 git diff 里很可能还是会被标红警告，因为Git不看渲染效果，只认文件里的原始字节。

说到底，让空格和制表符显示出来只是第一步。真正的挑战在于，如何让整个团队的成员看到同一套符号，并遵循同一套规则来保存文件。这后面还有缩进检测、自动转换、保存钩子等一系列环节，哪一个环节没跟上，都可能前功尽弃。