symbol.search仅定义字符串search()方法的匹配行为，不参与权限验证；它只接收被搜索字符串并返回索引，无法获取请求、会话或用户上下文，故不能用于接口鉴权，正确做法是通过网关、中间件、数据层等标准分层机制实现权限控制。
Symbol.search 本身不处理权限验证，它只定义对象在被 String.prototype.search() 调用时的搜索行为。把权限验证逻辑“塞进” Symbol.search 是误用，既违背语义，也难以集成到真实权限系统中。
Symbol.search 的真实职责
它仅影响字符串的 search() 方法执行路径：当传入一个带 [Symbol.search] 方法的对象时，JS 引擎跳过正则解析，直接调用该方法并返回其结果（必须是数字索引或 -1）。它不是钩子、拦截器，也不参与请求生命周期。
- 它不接触 HTTP 请求、路由、用户会话或 token
- 它无法阻止或重定向调用，只能返回一个匹配位置
- 它的上下文只有被搜索的字符串，没有 req/res、context 或 auth info
为什么不能用于全局搜索接口的权限控制
全局搜索接口（如 /api/search?q=xxx）属于服务端业务逻辑层，涉及鉴权、限流、字段过滤、数据源路由等。Symbol.search 运行在字符串操作层面，发生在任意 JS 环境中（前端、Node.js、Worker），与接口路由完全无关。
- 你无法在 Express/Koa/Fastify 的中间件里“触发”某个对象的 Symbol.search 来做鉴权
- 即便你在请求处理器里手动调用
query.search(customSearcher)，那也只是对 query 字符串做预处理，和“是否允许搜索”毫无关系 - 权限决策需要读取用户角色、资源策略、租户上下文——这些 Symbol.search 根本拿不到
真正该用的位置：搜索关键词的语义预处理
Symbol.search 合理的应用场景，是封装**关键词解析规则**，比如：
- 识别并提取带前缀的搜索指令：
"@user john"→ 提取john并标记为用户搜索 - 支持自然语言短语自动分词：
"最近三天订单金额大于500"→ 解析出时间范围、字段、条件 - 统一处理别名/同义词：
"笔记本"自动映射为["laptop", "notebook", "pc"]
这类逻辑可封装为一个 SearchQueryParser 对象，实现 [Symbol.search]，供上层统一调用，但权限仍需由独立的鉴权中间件完成。
权限验证该怎么做（简明建议）
对全局搜索接口的权限控制，应使用标准分层方式：
- 接入层校验：网关或反向代理检查 JWT、API Key、IP 白名单
-
路由级守卫：框架中间件（如 NestJS Guard、Express middleware）验证用户是否有
search:read权限 - 数据层过滤：根据用户所属组织/角色，自动注入 SQL WHERE 条件或 Elasticsearch ACL 查询
- 字段级脱敏：搜索结果返回前，移除用户无权查看的字段（如 salary、id_card）
这些环节都和 Symbol.search 无关，也不应强行耦合。
