优先用 submit 事件统一处理所有文本输入框的 trim 操作，因其覆盖全部场景、不依赖焦点流转、兼容动态字段，且能确保服务端前的数据洁净；onblur/onkeyup 等易漏粘贴、自动填充等路径，且破坏框架响应式更新。
直接结论：优先用 submit 事件统一处理，不推荐 onblur、onkeyup 或内联 onkeypress —— 容易漏场景、破坏用户体验、或根本无效。
为什么不能只靠 onblur 去空格
用户可能跳过失焦直接点提交按钮，onblur 根本不触发；即使触发，也只清理单个字段，无法保证所有文本输入框同步处理。更麻烦的是：如果用户先 blur 再修改值（比如回退编辑），onblur 已经改过一次，后续逻辑可能误判“值被用户主动改过”。
- 仅适用于需要实时反馈的极少数场景（如用户名格式预检）
- 必须手动触发
input或change事件，否则 Vue/React 等框架监听不到值变化 - 对动态插入的 input（如表格行新增）需重新绑定，容易遗漏
submit 事件中统一 trim() 是最稳方案
浏览器在真正发出请求前会触发 submit，此时遍历并清理所有目标字段，既覆盖全部输入类型，又不影响表单重置逻辑（因为只改 value，不碰 defaultValue）。
- 目标选择器要精准：
input[type="text"], input[type="email"], input[type="search"], textarea—— 明确排除hidden、checkbox、radio、file - 动态字段（如 JS 插入的 input）只要在 submit 时已挂载到 DOM，就能被
querySelectorAll捕获 - 若用了
e.preventDefault()后手动构造FormData，仍需在收集前调用.trim()，因为FormData读取的是当前value快照
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());
});
onkeyup 和 onkeypress 的实际缺陷
这类内联写法看似“实时”，但问题集中：粘贴（Ctrl+V）、拖拽文本、IME 输入、自动填充（Autofill）产生的空格完全绕过监听；onkeypress 依赖已废弃的 charCode，Chrome 120+ 和 Safari 中行为不可靠。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
-
onkeyup="this.value=this.value.replace(/\s+/g,'')"会误删中间空格，不符合“仅去首尾”需求 -
onkeypress="return event.charCode !== 32"对粘贴无效，且在移动端 WebView 中常失效 - 正则
/[, ]/g这类写法是业务定制过滤，不是通用空格清理，别混用
特殊空白符（全角空格、零宽空格）怎么办
String.prototype.trim() 只处理 ASCII 空白符（U+0009–U+000D、U+0020），对全角空格（U+3000）、不间断空格（U+00A0）、零宽空格（U+200B）等无能为力。前端无法 100% 覆盖所有情况。
- 服务端必须做二次校验和清理，不能信任前端 trim 结果
- 如需前端增强，可用正则
str.replace(/^[suFEFFu3000]+|[suFEFFu3000]+$/g, '')，但注意性能开销 - 移动端键盘、微信内置浏览器、某些 IME 更容易输入非标准空格，这点常被忽略
真正关键的不是“怎么写 trim”，而是想清楚：哪些空格必须前端拦、哪些必须后端兜底、哪些交互路径（粘贴/自动填充/快捷键）会被现有逻辑绕过——这些才是上线后出问题的高发点。
