问题
GlobalSwitchMask 会把 16 个 switch 开关状态镜像到 fast_mark 的第 32–47 位（switchN → 第 N+31 位）。此时如果用户在配置中对同一位使用 fast_mark（如 fast_mark 39），matcher 会静默恒真/恒假，产生难以排查的错误分流。
真实案例：msf 项目（scoltzero/msf）的 config 模板曾在「指定客户端直连」分支使用 fast_mark 39，与 switch8（Prefer IPV4，第 39 位）撞位，导致其 client_ip 白名单功能完全失效——matcher 恒真，所有查询都命中该分支。
建议加固
fast_mark 插件解析配置时，若 ID 落在 32–47 且 GlobalSwitchMask 已启用，直接报错拒绝启动，例如：
FATAL: fast_mark ID 40 collides with switch state bits 32-47, pick 0-31 or 48-63
已验证
我们在本地对 plugin/matcher/fast_mark/fast_mark.go 加了该校验并交叉编译验证：
- 旧二进制 +
fast_mark 40 配置 → 静默接受（直到端口绑定才因其他原因退出），撞位无任何提示
- 加固后二进制 +
fast_mark 40 → 插件初始化即 FATAL，错误信息直指撞位原因
这样可以把"配置了撞位 ID"从静默行为错误变成启动期显式错误。
问题
GlobalSwitchMask会把 16 个 switch 开关状态镜像到 fast_mark 的第 32–47 位（switchN→ 第N+31位）。此时如果用户在配置中对同一位使用fast_mark（如fast_mark 39），matcher 会静默恒真/恒假，产生难以排查的错误分流。真实案例：msf 项目（scoltzero/msf）的 config 模板曾在「指定客户端直连」分支使用
fast_mark 39，与 switch8（Prefer IPV4，第 39 位）撞位，导致其 client_ip 白名单功能完全失效——matcher 恒真，所有查询都命中该分支。建议加固
fast_mark插件解析配置时，若 ID 落在 32–47 且 GlobalSwitchMask 已启用，直接报错拒绝启动，例如：已验证
我们在本地对
plugin/matcher/fast_mark/fast_mark.go加了该校验并交叉编译验证：fast_mark 40配置 → 静默接受（直到端口绑定才因其他原因退出），撞位无任何提示fast_mark 40→ 插件初始化即 FATAL，错误信息直指撞位原因这样可以把"配置了撞位 ID"从静默行为错误变成启动期显式错误。