最可靠方式是在submit事件中批量trim文本类表单元素的value值，仅处理text/email/search/textarea，跳过hidden/checkbox/radio/select，不改defaultValue，动态插入元素也能捕获；需用正则补充清理全角空格等非ASCII空白；服务端校验不可省。
submit事件中统一trim所有文本类input和textarea
表单提交前去首尾空格，最可靠的方式是在submit事件里批量处理，而不是依赖blur或input等中间时机——用户可能跳过失焦直接点提交，那些时机根本来不及触发。
关键点是只处理真正需要的元素类型，避免误伤：
-
input[type="text"]、input[type="email"]、input[type="search"]、textarea必须处理 -
input[type="hidden"]、input[type="checkbox"]、input[type="radio"]、select一律跳过 - 只改
value，不动defaultValue，否则form.reset()会失效 - 动态插入的字段（如JS新增的
input）只要在submit时存在于DOM中，就能被querySelectorAll捕获到
示例代码：
document.querySelector('form').addEventListener('submit', function(e) {
this.querySelectorAll('input[type="text"], input[type="email"], input[type="search"], textarea')
.forEach(el => el.value = el.value.trim());
});
遇到全角空格、不间断空格等特殊空白字符怎么办
String.prototype.trim()只清除ASCII范围内的空白符（U+0009–U+000D、U+0020），对中文输入法常带的全角空格（U+3000）、NBSP（U+00A0）、零宽空格（U+200B）完全无效。用户复制粘贴一段含这些字符的内容，.trim()后依然“看着空、实际不空”。
立即学习“前端免费学习笔记（深入）”；
稳妥做法是扩展正则清理：
- 用
.replace(/^[\s\uFEFF\u2000-\u200F\u2028-\u202F\u2060-\u206F\u3000]+|[\s\uFEFF\u2000-\u200F\u2028-\u202F\u2060-\u206F\u3000]+$/g, '')覆盖常见非ASCII空白 - 或者更简洁地：先
.trim()，再额外清理\u3000和\u00a0：.trim().replace(/[\u3000\u00a0]/g, '') - 服务端校验不可省——前端任何trim都只是体验优化，不是数据保障
别在onkeyup/oninput里实时删空格
有人写onkeyup="this.value=this.value.replace(/\s/g,'')"或监听input事件暴力删所有空白，这会导致两个严重问题：
- 用户想输“张 三”（姓名中间有空格）被强制变成“张三”，语义破坏
- 输入过程中光标频繁跳转（尤其在iOS Safari上），体验极差
除非业务明确要求“禁止任何空格”（如用户名、token），否则不该删中间空格。首尾空格的清理，只该发生在提交前或失焦时，且仅限trim()语义——即两端，不碰中间。
使用FormData构造时trim容易被忽略
如果用了e.preventDefault()并手动构建FormData，比如new FormData(form)，那前面在submit里做的.trim()依然有效——因为FormData读取的是当前value值。但如果你是手写append，比如fd.append('name', input.value)，那就必须自己调.trim()，否则白忙一场。
另外注意：FormData对textarea和input一视同仁，都按字符串取值，所以textarea.value.trim()同样适用。
真正容易被忽略的是异步场景：比如提交前发个校验请求，再决定是否真提交。这时若校验逻辑里没trim，就可能把带空格的原始值传给后端，导致前后端判断不一致。
