Sublime Text 不支持仅检测不删除尾部空格的只读模式，trim_trailing_white_space_on_save 是纯执行型设置，开即删、关即停；需借助 Git diff、Trim Trailing White Space 命令或 pre-commit hook 实现检测与拦截。
Sublime 本身不提供“检测但不删除”的只读模式，trim_trailing_white_space_on_save 是纯动作型设置——开就删，关就不动，没有中间态。想在提交前确认有没有尾部空格，得靠组合策略，而不是指望一个开关同时满足“显示警告”和“自动清理”。
为什么不能只检测不删？
Sublime 没有内置的「高亮/标记尾部空格但不自动删」功能。它的 trim_trailing_white_space_on_save 和 trim_automatic_white_space 都是执行型逻辑，触发即清理，不提供视觉反馈或暂存机制。所谓“检测”，实际要靠外部手段辅助验证。
- Git diff 是最准的“检测器”：提交前运行
git diff --check，会明确标出trailing whitespace行 - Sublime 的
Trim Trailing White Space命令执行后不保存文件，你可以先运行它，再看左侧边栏是否有未保存修改图标（●），有就说明确实存在尾部空格 - 如果开了
trim_trailing_white_space_on_save，保存后空格已消失，Git diff 就不会报 —— 这不是检测失效，而是问题已被解决
如何让 Git 提交前自动拦截尾部空格？
靠 Sublime 自身做不到“提交前阻断”，但可借 Git hooks 实现真正意义上的预防。这不是编辑器配置，而是版本控制层加固：
- 在项目根目录创建
.git/hooks/pre-commit文件，添加内容：#!/bin/sh if git diff --cached --check | grep -q 'trailing whitespace'; then echo "Error: trailing whitespace detected in staged files" exit 1 fi
- 给该文件加执行权限：
chmod +x .git/hooks/pre-commit - 这样每次
git commit前都会检查暂存区，有尾部空格直接中止，并提示具体位置 - 配合 Sublime 的
trim_trailing_white_space_on_save，能形成“编辑时清理 + 提交前兜底”的双保险
哪些文件类型必须禁用自动清理？
盲目全局开启 trim_trailing_white_space_on_save 会破坏语义，尤其在以下场景：
-
text.markdown：两个空格 + 换行是硬换行语法，删掉后渲染成段落而非换行 -
source.makefile：Makefile 中行尾空格可能参与变量展开或影响命令对齐 -
text.tex或text.latex：注释对齐、宏定义缩进常依赖空格，删错会导致编译失败或排版错乱 - 解决方法不是关全局，而是用语法专属设置：打开一个
.md文件 →Preferences → Settings – Syntax Specific→ 加入"trim_trailing_white_space_on_save": false
手动清理老文件时最容易忽略的点
用 Trim Trailing White Space 命令或正则 \s+$ 批量处理历史文件时，真正的风险不在“删多了”，而在于“删了不该删的上下文”：
- YAML 文件里，块序列（
- item）后的空格可能是缩进的一部分，\s+$会误伤；应优先用trim_trailing_white_space命令，它只清“非缩进用途”的尾部空白 - Python 中
return x（return 后带空格）会被删，但这是合法且常见的写法，不影响运行；重点应放在def foo():这类函数声明后的空格上，它们无意义且易被 Git 报警 - 批量操作前务必
git add -p分块审查，别信“Replace All”后的肉眼扫视
最常被低估的是作用域优先级：用户设置、项目设置、语法专属设置、插件设置四层叠加，trim_trailing_white_space_on_save 生效与否，取决于哪一层最后拍板。调试时不要只盯 JSON 格式，先看右下角语法名，再查项目文件，最后翻插件文档——顺序错了，改十遍也没用。
