VSCode 保存时自动 trim trailing whitespace 可通过内置配置 "files.trimTrailingWhitespace": true 开启，无需插件；需检查工作区覆盖、文件类型排除、只读状态及焦点位置等常见失效原因。
VSCode 保存时自动 trim trailing whitespace 怎么开
直接开，不用装插件。VSCode 内置支持，靠 "files.trimTrailingWhitespace" 这个配置控制。
打开设置（Ctrl+, 或 Cmd+,），搜 trim trailing whitespace，勾上就行。或者手动改 settings.json：
{
"files.trimTrailingWhitespace": true
}
这个开关生效范围是「当前工作区」或「用户全局」，取决于你在设置界面点的是哪个层级的编辑按钮。
为什么有时候保存了却不 trim？常见原因有哪些
不是配置没起作用，而是被其他设置或文件类型覆盖了。重点排查这几点：
-
"files.trimTrailingWhitespace"被某个 workspace 的.vscode/settings.json设为false，优先级更高 - 当前文件类型被排除在 trim 范围外：比如
"files.trimTrailingWhitespace"是全局开启的，但"[markdown]": { "files.trimTrailingWhitespace": false }单独关掉了 markdown - 文件是只读、未保存过（比如新 tab 没命名）、或正在被外部进程锁定，VSCode 不会修改内容
- 你按的是
Ctrl+S，但编辑器焦点不在编辑器区域（比如在终端或搜索框里），实际没触发保存
要不要配合 editor.formatOnSave 一起用
可以配，但得小心顺序和冲突。两者独立触发：
-
editor.formatOnSave调用格式化器（如 Prettier、ESLint），可能自己也会删空格，也可能留着——取决于格式化器配置 -
files.trimTrailingWhitespace是 VSCode 自己在保存前最后一刻无条件执行，不依赖语言服务，更稳定 - 如果同时开了两个，且格式化器输出末尾带空格，VSCode 仍会在格式化后立刻 trim 一遍，不会多出空格
- 但若格式化器本身有副作用（比如重排 import 行并加空行），再 trim 可能破坏其意图，这时建议关掉
files.trimTrailingWhitespace，全交给格式化器管
团队协作时要注意什么
这个配置不会进 Git，但它的效果会进代码。容易引发两类问题：
- 多人共用一个仓库，有人开、有人关，每次保存都导致整行 diff（尤其空行前后），Git 记录全是空格变更
- CI/CD 流水线跑 ESLint 或 Prettier 时提示「trailing spaces」，但本地看不出来——说明 CI 环境没开
files.trimTrailingWhitespace，或用了不同格式化规则 - 稳妥做法：把
"files.trimTrailingWhitespace": true写进项目根目录的.vscode/settings.json，并加到.editorconfig里同步约束：trim_trailing_whitespace = true
真正麻烦的不是怎么开，而是“谁在什么时候、以什么粒度统一它”。空格看着小，混在换行符、编码、缩进风格里，就是第一个崩掉的雪球。
