sublime中tab键行为由translate_tabs_to_spaces控制，设为true才插空格；detect_indentation为true时会覆盖手动设置，需设为false并重载文件。
Tab 键按下去还是 \t？先关掉 detect_indentation
不是设置没写对，而是 Sublime 默认会“自作主张”——只要 detect_indentation 是 true（默认值），它一打开文件就扫描前几行缩进，立刻把你设好的 translate_tabs_to_spaces 和 tab_size 给覆盖掉。比如一个旧 Python 文件开头有 Tab，Sublime 就直接给你切回 translate_tabs_to_spaces: false，状态栏还只显示 Tab Width: 4，让你误以为生效了。
- 必须在 Preferences → Settings – User 里加这一行：
"detect_indentation": false - 改完不用重启，但已打开的文件得手动重载（
Ctrl+Shift+P→Reload Syntax或关再开） - 如果项目里混着不同缩进风格，关掉检测反而是最稳的选择；想保留检测又控制结果？那就得进语法专属设置里显式写死
新建文件/按 Tab 键仍插 \t？检查 translate_tabs_to_spaces 是否真为 true
tab_size 只管显示宽度和转换时的空格数量，它不决定 Tab 键行为；真正开关是 translate_tabs_to_spaces。设成 false 或压根没写，Tab 键永远插 \t，哪怕状态栏写着 Spaces: On（那其实是假的）。
- 用户设置里至少要有这两项：
"translate_tabs_to_spaces": true，"tab_size": 4（或2，按项目规范） - 某些文件类型（如
.env、纯文本）没语法高亮，Sublime 不走语法专属逻辑，全靠这俩全局配置兜底 - 按
Tab后不确定插的是啥？打开 View → Show White Space，箭头是\t，小点是空格
旧代码全是 Tab 缩进？Convert Indentation to Spaces 不是自动的
设置只影响「新输入」，不会动已有内容。哪怕你把 tab_size 改成 8，那些老 \t 还是 \t，Git diff 里照样报错、格式化工具也认不出来。
- 单文件处理：全选（
Ctrl+A），再执行Convert Indentation to Spaces（右键菜单或Ctrl+Shift+P搜） - 批量处理？Sublime 本身不支持跨文件操作。Linux/macOS 下用命令行：
find . -name "*.py" -exec sed -i 's/\t/ /g' {} \;（注意 macOS 的sed -i要加空字符串） - 如果文件底部提示“混合缩进”，Sublime 会禁用转换功能——得先手动删掉几行异常缩进，再试
格式化后缩进又乱了？那是 Prettier/Black 在“抢活”
Sublime 的 tab_size 和 translate_tabs_to_spaces 只管你按 Tab 键、自动缩进这些事，不管外部格式化工具输出。Prettier 看 .prettierrc，Black 看 pyproject.toml，它们完全无视编辑器设置。
- JS 项目用了
JsPrettier插件？得进插件设置里勾上auto_indent，并在prettier_options里显式写"tabWidth": 2 - Python 用 Black？它强制 4 空格，想统一就得改
pyproject.toml里的line-length和缩进相关项 - 最保险的做法：格式化完，再手动执行一次
Indentation: Convert to Spaces，确保落盘的是空格
真正麻烦的从来不是怎么配，而是各种优先级叠加：全局设置、语法专属设置、EditorConfig 插件、格式化工具、甚至保存时的 trim_automatic_white_space 都可能悄悄改掉你的空格。配完别急着写代码，先开个新文件按几下 Tab，再开个旧文件转一次缩进，最后跑一遍格式化——三步都对了，才算真的稳了。
