敏感词过滤不能在路由层实现，因为路由只匹配Method和Path，不解析Body；中间件无法安全读取/重置请求体，也无法劫持响应流；必须拆分为请求体预处理和响应包装器两步，并用Aho-Corasick等算法精准匹配语义内容。
路由层无法真正实现敏感词过滤——因为敏感词检查必须作用于请求体（如 JSON 字段值）或响应体内容，而 Echo 的路由匹配只看 Method 和 Path，不解析、不触碰 Body 或 ResponseWriter。
为什么不能靠路由中间件做敏感词过滤
很多人误以为在 echo.Group() 或某个路由前加个中间件就能“拦截敏感词”，但实际执行顺序是：路由匹配 → 中间件链 → Handler。此时 c.Request.Body 可能已被读取（如被 Bind() 消费），再次读取会返回空；而若在中间件里强行 io.ReadAll(c.Request.Body) 再塞回去，会破坏原始流状态，导致后续 Bind() 失败或 panic。
- 路由中间件拿到的是
*echo.Context，它不自动解析 body，也不提供对响应内容的写入控制 -
echo.MiddlewareFunc里没有 hook 响应体输出的机制，c.Response().Writer是只读接口，不能劫持最终写出的字节流 - 想在路由层“拒绝含敏感词的请求”，必须先完整解析 body（如 JSON）、遍历所有 string 字段——这已超出路由职责，属于业务校验范畴
真正可行的敏感词过滤位置：请求体中间件 + 响应包装器
必须拆成两步：一是预处理请求体（只对 POST/PUT 等有 body 的方法），二是包装 ResponseWriter 拦截输出。两者都需手动接管 IO 流，不能依赖路由机制。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 请求体过滤：用
io.NopCloser(bytes.NewBuffer(filteredBody))替换c.Request.Body，且仅在c.Request.Method为POST或PUT时触发 - 响应体过滤：需自定义
echo.Response包装器，在Write()或WriteHeader()后对bytes.Buffer内容做ahocorasick.Trie匹配，再写回原 writer - 避免重复解析：高频接口必须用
sync.Pool复用bytes.Buffer和json.Decoder，否则 GC 压力陡增
敏感词匹配不能只靠字符串 contains
直接用 strings.Contains() 扫描整个 body 字符串，会误杀字段名、数字、URL 路径等非语义内容，且完全无法应对变形攻击（如 “敏*感词”、“mǐn gǎn cí”、“mi敏gan”）。
- 必须先解析 JSON，递归遍历所有
string类型 value，对每个值单独过筛 - 生产环境建议用
ahocorasick.Trie构建敏感词树，单次扫描完成多词匹配，时间复杂度从 O(n×m) 降到 O(n) - 若需支持拼音/同音/星号通配，就得引入分词或规则引擎（如
gojieba+ 自定义替换逻辑），不能再走纯中间件路径
最易被忽略的一点：CLI 脚本、定时任务、MQ 消费器如果复用了同一套 DB 连接池和敏感词 Trie 实例，但没加载请求/响应过滤逻辑，那它们处理的数据就完全游离在防护之外——路由中间件对此类调用零感知。
