echo.middlewarefunc是拦截非法字符的正确入口，因其符合func(echo.context) error签名，可在路由匹配前对rawquery、escapedpath及请求体原始字节进行正则检测，避免解码掩盖恶意payload。
为什么 echo.MiddlewareFunc 是拦截非法字符的正确入口
因为 Echo 的中间件必须符合 echo.MiddlewareFunc 类型签名（func(echo.Context) error），任何在路由匹配前做请求体/参数清洗或拒绝的操作，都得走这个接口。用 echo.HandlerFunc 或普通 handler 写拦截逻辑，会错过前置校验时机，比如还没进路由就该拦住含 %00、<script></script>、控制字符（ -、 - ）的请求。
如何用正则预编译 + c.Request().URL.RawQuery 拦截 URL 中的非法字符
URL 查询参数最容易藏非法字符，但 c.QueryParam() 会自动解码，导致原始恶意 payload 被掩盖。必须直接读 c.Request().URL.RawQuery 和 c.Request().URL.EscapedPath()，再用预编译正则匹配。
- 用
regexp.MustCompile(`[ - - "'\%00-%08%0B%0C%0E-%1F]`)覆盖常见危险字符（含 URL 编码形式） - 对
RawQuery和EscapedPath()分别检测，避免漏掉路径注入（如/api/user/%2e%2e%2fetc/passwd） - 匹配到立即返回
c.String(400, "invalid characters detected")并 return，不调用next(c) - 不要用
strings.Contains()—— 它无法识别 URL 编码后的非法字符
POST/PUT 请求体里的非法字符怎么安全检测
不能直接读 c.Request().Body 两次（HTTP Body 是单次读取流），得用 c.Request().Body = io.NopCloser(bytes.NewBuffer(buf)) 回填。更稳妥的做法是：只对已知文本类型（application/json、application/x-www-form-urlencoded）做检测，跳过 multipart/form-data 和二进制类型。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 先检查
c.Request().Header.Get("Content-Type")是否匹配文本 MIME 类型 - 用
io.LimitReader(c.Request().Body, 1024*1024)限制最大读取 1MB，防 OOM - 读出字节后，用和 URL 相同的正则检测原始字节（不是字符串），避免 UTF-8 解码干扰
- 检测通过后，用
bytes.NewReader(buf)重置 Body，否则后续 handler 会读不到数据
为什么不能在中间件里调用 c.Bind() 或 c.FormValue()
这些方法会触发自动解析和解码，把 %3Cscript%3E 变成 <script></script>，导致你写的非法字符检测失效——你检测的是解码后的干净字符串，而攻击者真正发送的是编码前的恶意 payload。所有检测必须在任何解码动作之前完成，也就是在 c.Request().Body 或 RawQuery 层级操作。
另外注意：Go 的 net/http 默认会拒绝含空字节（ ）的 URL，但某些代理或前端可能提前解码，所以不能依赖底层过滤。真正可靠的拦截点只有你自己写的中间件。
