先说结论：处理非标准字符串输入时，核心策略并非“一刀切地过滤”，而是要清楚数据来源与去向，再有针对性地进行清洗或转义。JavaScript 中常见的坑包括不可见字符、编码混搭、BOM 头、多余空白、HTML 实体以及转义序列——这些问题会导致字符串解析报错、比较失败，甚至埋下安全漏洞。下面逐一拆解。
识别并剥离 BOM 与控制字符
UTF-8 文件开头有时会携带 BOM（uFEFF），某些编辑器或后端响应可能悄悄将它塞入数据。而 ASCII 控制字符（如 u0000 到 u001F，不包括空格、制表符、换行符）常被用来隐藏注入内容或干扰正常解析。
- 用正则剔除常见控制字符（保留空格、换行、制表符）：
str.replace(/[u0000-u0008u000Bu000Cu000E-u001Fu007F-u009F]/g, '') - 检测并移除 BOM：
str = str.replace(/^uFEFF/, '')，建议在接收到字符串后第一时间处理 - 注意：不要盲目使用
trim()替代——它只去除首尾空白，对中间的零宽字符（比如u200B）完全无效
统一编码与 Unicode 规范化
用户粘贴、跨平台复制或旧系统导出的数据中，经常出现视觉相同但码点不同的字符——全角数字 １ 与半角 1 就是典型例子。Unicode 标准化可以显著提升数据一致性。
- 优先使用
str.normalize('NFC')（兼容组合形式），适用于大多数显示与比较场景 - 如需彻底扁平化（例如搜索、用户名校验），可结合替换：
str.normalize('NFD').replace(/[u0300-u036f]/g, '')去除变音符号 - 避免直接用
escape或encodeURI处理原始字符串——它们专为 URL 场景设计，会破坏可读性
安全处理 HTML 实体与转义序列
从富文本编辑器、API 返回或用户输入获取的字符串，可能包含 &、< 或 é 这类实体。是否需要解码，完全取决于后续用途。
- 若用于 DOM 渲染（如
textContent），无需手动解码——浏览器会自动处理，且更安全 - 如果需要还原为原始字符（比如日志分析、数据清洗），可用临时 DOM 元素解码：
new DOMParser().parseFromString(`${str}
`, 'text/html').documentElement.textContent - 务必警惕
eval、Function或innerHTML直接执行未清洗的字符串——即使已解码，仍可能暗含恶意脚本
按用途选择清洗策略
不存在“万能清洗函数”。同一个字符串，在表单验证、URL 构造、JSON 序列化、正则匹配中使用时，要求千差万别。
- 用于正则匹配前：先执行
normalize()，再确保特殊字符被正确转义（例如str.replace(/[.*+?^${}()|[]\\]/g, '\\$&')） - 构造 URL 参数：使用
encodeURIComponent()，而非encodeURI()或手动替换 - 存入数据库或发送 API 请求体：通常保持原始语义，由后端负责校验；前端只需确保 JSON 序列化不报错（
JSON.stringify会自动处理绝大多数边界情况）
