必须改用户配置里的"draw_white_space":"all"，这是唯一稳定生效的方案；菜单「show hidden characters」仅临时切换、不持久、不触发重绘、不显示换行符¶，且版本兼容性差。
必须改用户配置里的 draw_white_space 为 "all"，其他方式（比如菜单勾选）要么不持久，要么只显示部分字符——这是唯一稳定生效的方案。
为什么菜单里的「Show Hidden Characters」不推荐
Sublime 的 View → Show Hidden Characters 实际只是临时切换 draw_white_space 的布尔状态，等价于在 "all" 和 "none" 之间切。它不保存、不跨会话、不触发重绘已打开文件，关掉编辑器再开就失效。更关键的是：这个菜单项在某些版本或主题下根本不会出现，属于不可靠路径。
- 它不控制换行符显示（
¶），哪怕勾选了也不会出现 - 它无法区分空格（
·）和制表符（→）的渲染逻辑，纯靠猜测 - 多人协作时，别人没开这个菜单，你看到的“对齐”可能是假象
draw_white_space 的三个合法值怎么选
这个配置项只接受字符串，不是布尔值；写 true、on 或漏引号都会导致整个用户配置解析失败，设置静默失效。
-
"none"：默认值，什么也不画，缩进全靠猜 -
"selection"：只在鼠标或键盘选中的区域里显示·和→，漏掉未选中的缩进行首、空行、注释行尾空格 -
"all"：唯一能持续显示所有空格、\t、行尾空白和换行符的选项——但注意：换行符符号¶还需额外配show_line_endings
显示出来了，但 → 错位或 · 看不清怎么办
符号渲染受两个因素影响：一是当前配色方案（color scheme）对 · 和 → 的颜色/透明度定义，二是字体本身对这些 Unicode 符号的支持程度。很多深色主题把 · 设得极淡，甚至接近背景色。
- 先确认
translate_tabs_to_spaces是false：如果设为true，文件里实际没有\t字符，自然不会显示→ - 右下角状态栏显示
Tab Width: 4或Spaces: 2，仅代表 Sublime 当前识别的缩进风格，不影响→是否渲染 - 若
→显示模糊或错位，大概率是混合缩进：某行用 4 个空格，另一行用 1 个\t（Tab Width 4），视觉上看似对齐，但字符类型不同——此时执行命令面板里的Convert Indentation to Spaces更治本 - 临时排查可用
Ctrl+Shift+P输入Toggle White Space，它不改配置，只运行时覆盖，适合 Code Review 时快速比对
大文件卡顿、复制粘贴出错这些副作用怎么防
开启 "draw_white_space": "all" 后，Sublime 要实时扫描并绘制每处空白字符。对 >10MB 的日志或 minified JS 文件，可能明显拖慢滚动和输入响应。
- 不要在用户配置里加
"draw_white_space": "all"后就一劳永逸——建议配合trim_trailing_whitespace_on_save和detect_indentation一起用，减少后续人工干预 - 复制前避免鼠标拖选：用
Ctrl+L（选整行）或Ctrl+Shift+↑/↓（多行）更安全，防止意外选中行尾·导致粘贴后多空格 - 粘贴到 Python、JSON 或 Makefile 前，务必检查目标环境是否允许开头 Tab——
→看着像缩进，但如果是\t，在 Python 里就是语法错误 - Git 提交前别只信 Sublime 的显示：混用
\t和空格的文件，git diff里仍可能标红，因为 Git 不看渲染，只看字节
真正难的不是让空格露出来，而是让团队所有人看到同一套符号、用同一套规则存进去。显示只是第一层，后面缩进检测、自动转换、保存钩子，一个都不能少。
