开启 "draw_white_space": "all" 是唯一可靠、全局生效的空格和Tab可见方案，能稳定显示空格为·、Tab为→，配合 trim_trailing_whitespace_on_save 等设置可彻底解决缩进混乱问题。
直接开启 draw_white_space 并设为 "all"，空格和 Tab 就会稳定显示为 · 和 → —— 这是唯一可靠、全局生效的方案。
怎么让空格和 Tab 永久可见
临时勾选菜单里的 Show Hidden Characters 只在当前会话有效，且容易被误关。真正管用的是改配置：
- 打开
Preferences → Settings - 在右侧用户设置（User Settings）中添加这一行：
"draw_white_space": "all"
- 保存后立即生效，无需重启
注意：别写成 "draw_white_space_on": true 或其他变体 —— Sublime 只认这个 exact key 和三个合法值："none"、"selection"、"all"。"boundary" 虽然存在，但行为不一致（比如忽略纯空格行首尾），调试缩进问题时反而漏掉关键信息。
为什么 "all" 是 Python/Markdown 用户的刚需
Python 报 IndentationError、Markdown 表格错位、YAML 缩进失效……八成源于肉眼不可见的混用。开启后你能立刻分辨：
huaweicloud-python-sdk-helper
下载
华为云 Python SDK 查询工具。自动发现已安装 SDK 的服务包、Client类、API 方法、入参详情、类信息（__init__ 参数、属性、类型、描述），支持关键字搜索，快速定位目标 API 使用方法。
- 一个缩进是 4 个
·（空格）还是 1 个→（Tab） - 行尾有没有偷偷多打的
·（Trailing Spaces） - 不同行的缩进是否真的一致（比如某行是 2×
→，另一行是 8×·）
尤其在协作场景下，别人提交的文件里藏了 Tab，你本地没开显示就直接改，很容易把混合缩进“固化”成更难修的格式。
配合哪些设置才能真正用起来
单开 draw_white_space 只是第一步。要避免干扰又不漏问题，建议组合配置：
- 加
"trim_trailing_white_space_on_save": true：保存时自动删行尾空格，Git diff 更干净 - 加
"translate_tabs_to_spaces": true：按 Tab 键时插入空格而非 Tab，从源头减少混用 - 加
"tab_size": 4：确保空格缩进宽度和显示对齐（否则→看起来比实际占位宽） - 排除特殊文件类型：
"trim_trailing_white_space_on_save_exclude": ["text.markdown", "source.makefile"]
防止 Markdown 段落缩进或 Makefile 命令前导 Tab 被误删
这些设置都写在同一个用户 settings 文件里，彼此不冲突，但缺一环就可能让 · 和 → 显得“多余”或“没用”。
最常被忽略的是：右下角状态栏显示的 Tabs 或 Spaces 只反映当前文件的缩进模式，不是显示开关。哪怕它写着 Spaces: 4，如果没开 draw_white_space，空格依然隐形 —— 别被这个误导。
