直接开启files.trimTrailingWhitespace:true即可保存时自动删除行尾空格，无需插件或Prettier；若未生效，常见原因包括文件只读、焦点不在编辑器、.editorconfig覆盖、语言ID识别错误或工作区配置显式设为false。
直接开启 files.trimTrailingWhitespace 就能保存时自动清理行尾空格，不需要插件、不依赖 Prettier 或 ESLint；但若没生效，大概率是被只读状态、.editorconfig 覆盖或语言 ID 识别错误拦住了。
保存时自动删行尾空格：必须设对位置和值
这个行为默认关闭，必须显式设为 true 才起作用。关键不是“有没有开”，而是“在哪开”：
- 优先写进项目根目录的
.vscode/settings.json，内容仅需一行：{"files.trimTrailingWhitespace": true} - 避免只改用户级设置（
settings.json全局路径），否则别人拉代码后 Git diff 会突然冒出一堆空格变更 - 检查是否有语言专属覆盖，比如
"[markdown]": {"files.trimTrailingWhitespace": false}—— 这种配置会直接关掉该语言的清理 - 确认右下角状态栏显示的语言 ID 正确（如
javascript，不是plaintext），否则语言级配置压根不加载
手动触发全量清理：用命令，不是快捷键
VSCode 没有默认绑定的单键快捷键来执行清理，但内置命令 editor.action.trimTrailingWhitespace 可以按需调用，且行为精准：
- 没选中任何内容 → 清理整个文件所有行尾空格（含空行里的空格）
- 选中若干行 → 只清理选中范围内的行尾空白
- 光标停在某行末（未选中整行）→ 仅清理该行尾部
- 可在
keybindings.json中自定义快捷键，例如：{"key": "ctrl+alt+t", "command": "editor.action.trimTrailingWhitespace"}
为什么保存后空格还在？常见拦截点
不是配置失效，而是触发条件没满足。以下情况会让 files.trimTrailingWhitespace 完全不运行：
- 文件是只读的（Git LFS 锁定、权限为 read-only、被其他进程占用）
- 按
Ctrl+S时焦点不在编辑器内（光标停在终端、搜索框或侧边栏） - 装了 EditorConfig 插件，且项目根目录有
.editorconfig，其中写了trim_trailing_whitespace = false -
.vscode/settings.json里某处显式设了"files.trimTrailingWhitespace": false（它会覆盖用户级设置） - 某些语言模式（如
makefile、shellscript）在 VSCode 内置逻辑中默认禁用该行为，需单独显式开启
和格式化工具混用时的真实顺序
files.trimTrailingWhitespace 和 editor.formatOnSave 完全独立，但执行顺序固定：先格式化 → 再 trim 行尾空白。这会导致一些隐性问题：
- 如果 Prettier 输出带行尾空格，VSCode 还会再扫一遍删掉 —— 看似“双重保险”，实则没必要
- 如果 Prettier 重排 import 并插入空行，VSCode 后续的 trim 可能破坏其对齐意图
- ESLint 的
no-trailing-spaces规则若被eslint-config-prettier禁用，VSCode 的 trim 仍在默默干活，容易造成规则认知错位 - 真要统一控制，建议关掉
editor.formatOnSave，只留files.trimTrailingWhitespace+files.trimFinalNewlines+files.insertFinalNewline
空格问题看着小，但协作中最容易暴露配置断层；尤其空行里的空格会被 files.trimTrailingWhitespace 一并清理——这点常被忽略，却直接影响 Git diff 的可读性。
