“Trim Trailing Whitespace”不删缩进空格，因它仅处理行尾空白，不触碰行首缩进、HTML标签间换行、全角/Unicode空格，也不识别语义上下文（如<pre>或<textarea>），更非缩进统一或HTML压缩功能。
编辑器“Trim Trailing Whitespace”功能为什么没清掉缩进空格？
它只处理行尾（line end）的空白字符，对行首缩进、标签间换行、 或全角空格完全无感。很多用户误以为开了这个选项就能让 HTML 源码“整齐”，结果发现 <div> 和 </div> 之间多出的空行、textarea 后面的制表符依然存在。
常见错误是把「清理空格」等同于「统一缩进」或「压缩 HTML」——这两者根本不是一回事。
- 该功能触发时机通常是保存文件时，部分编辑器（如 VS Code）默认仅对当前光标所在行或已修改行生效，未改动区域不会被扫描
- 它不识别 HTML 语义：不会跳过
<pre>或<textarea>内容，可能误删本应保留的空格 - 无法处理 Unicode 空白符，比如
\u200b（零宽空格）、\u00a0（不间断空格），这些在复制粘贴内容中很常见
VS Code 中如何让 Trim 自动作用于所有行而非仅修改行？
默认设置下，VS Code 的 "files.trimTrailingWhitespace": true 只影响你编辑过的行。要让它真正“全局生效”，必须配合保存钩子和格式化配置。
- 在
settings.json中启用强制全文件扫描："editor.formatOnSave": true+"editor.formatOnSaveMode": "modifications"改为"modificationsIfAvailable"并搭配 Prettier 插件 - 单独使用内置 trim 功能时，需手动触发命令：Ctrl+Shift+P → 输入
Files: Trim Trailing Whitespace，这是唯一能扫完整文件的方式 - 若用 ESLint 或 Stylelint 校验 HTML，它们默认不接管空格逻辑；需额外配置
rules: { "no-trailing-spaces": "error" }并确保解析器支持 HTML（如 eslint-plugin-html）
HTML 标签间换行产生的空格间隙，靠编辑器 trim 能解决吗？
不能。浏览器把源码里 <p>\n <span>hello</span>\n</p> 中的换行和缩进渲染成一个空格，这不是“行尾空格”，而是 DOM 文本节点中的空白字符。编辑器的 trim 功能对此类空格完全不可见。
立即学习“前端免费学习笔记（深入）”；
- 这类空格属于 HTML 结构性空白（structural whitespace），需用 CSS 控制：
font-size: 0在父容器上，再为子元素设回正常字号 - 或改用
display: flex/display: grid布局，天然规避文本节点空白的影响 - 如果必须保留 HTML 可读性，可用注释消除换行：
<span>a</span><!-- --><span>b</span> - 构建阶段用
html-minifier处理更可靠，它能区分<pre>和普通标签，安全压缩
为什么提交表单前用 .trim() 清空输入值，和编辑器 trim 行尾空格不是一回事？
前者操作的是运行时 DOM 元素的 value 属性（字符串值），后者操作的是磁盘上的源码文件字节流。两者生命周期、作用域、字符集支持都不同。
-
.trim()在浏览器中执行，只处理 ASCII 空白（\s），对\u200b、\u3000（中文全角空格）无效；编辑器 trim 同样受限于其正则引擎，默认也不处理 Unicode 空白 - 表单提交场景中，用户可能粘贴带零宽字符的内容，此时需自定义清理：
el.value.replace(/[\s\u2000-\u206F\u2E00-\u2E7F\u3000-\u303F\u3099-\u309C\u30A0-\u30FF]+/g, '') - 编辑器 trim 是开发阶段行为，不影响最终页面表现；而
.trim()是运行时防御，防止脏数据进入后端
真正容易被忽略的是：HTML 源码里的空白，80% 不该靠编辑器“删”，而该靠构建流程压缩、CSS 控制渲染、JS 运行时净化三者分层处理。混用或依赖单一手段，迟早踩坑。
