trim()后必须显式判断query === ""才能防止空搜索，因trim(" ")返回""，而业务逻辑未校验会导致空请求；需先用(input ?? "").trim()防御null/undefined，再严格比对空字符串。
为什么直接用 trim() 还会触发空搜索？
常见现象是：用户输了一串空格后回车，trim() 确实清掉了首尾空格，但若输入全是空格（如 " "），trim() 后变成空字符串 ""，而业务逻辑没做二次判空，结果仍发了空查询请求。
根本原因在于：trim() 只处理空白字符（\s 类），不改变字符串是否“有意义”——它只是预处理步骤，不是校验终点。
- 必须在
trim()后显式检查length === 0或=== "" - 某些场景下用户可能输入制表符、全角空格等，
trim()默认不处理全角空格（ - 不要依赖
if (input.trim())—— 在 JS 中""是 falsy，但0、false、null也会被误拦，应明确比对字符串值
trim() 前要不要先做 null/undefined 防御？
搜索框的 value 通常不会是 null 或 undefined，但如果你从 props、state 或 event 参数中取值（比如 React 的 event.target.value），意外未定义仍可能发生。不防御会导致 Cannot read property 'trim' of undefined 错误。
- 推荐写法：
const query = (input ?? "").trim()（ES2020 空值合并） - 兼容旧环境可用：
const query = (input == null ? "" : input).trim() - 避免
input && input.trim()：当input是0或"0"时会被错误忽略
要不要用 trimStart() 和 trimEnd() 替代？
不需要。搜索场景要求的是“整体有效性”，首尾空格都得清，且最终要判断整个字符串是否为空。分开调用 trimStart() + trimEnd() 不仅冗余，还容易漏掉中间连续空格导致误判（虽然不影响空查询，但语义不清）。
-
trim()等价于trimStart().trimEnd()，但更简洁、可读性更高 - 部分老版本 Safari 对
trimStart/trimEnd支持不全，而trim()兼容性更好（IE9+） - 若需保留末尾空格（极少见），才考虑拆分；搜索框无此需求
实际提交前的完整校验链怎么写？
一个健壮的搜索触发函数，trim() 只是第一步。真正防止空查询，需要三步闭环：
function handleSearch(input) {
const query = (input ?? "").trim();
if (query === "") return; // 关键：显式拦截
if (query.length > 100) {
console.warn("搜索词超长，截断");
api.search(query.substring(0, 100));
} else {
api.search(query);
}
}
- 永远把
trim()和=== ""判空写在同一行逻辑里，别隔开 - 如果后端对搜索词有长度限制，校验必须放在
trim()之后（因为空格不计入有效长度） - 用户粘贴内容时可能带换行符或 BOM 字符，
trim()能处理换行符（\n、\r），但对 BOM（如\uFEFF）无效，必要时加.replace(/^\uFEFF/, "")
最常被跳过的其实是那个 if (query === "") —— 它看起来太简单，反而最容易被当成“没必要写”而漏掉。
