必须在c.Cookie()或c.Cookies()调用前，从c.Request().Header手动解析Cookie头字符串，按白名单过滤键值对后重写Header；否则框架已全量解析进内存，无法撤回。
怎么用中间件在解析前过滤非法未知 Cookie
必须在 c.Cookie() 或 c.Cookies() 被调用前拦截，否则框架已把所有 Cookie 解析进内存，再删也晚了。Echo 不提供“预读并筛选 Cookie”的内置机制，得自己从 c.Request().Header 里手动拆解 Cookie 头字符串，按规则过滤后重写 Header。
- 直接操作
c.Request().Header是唯一可靠方式：它尚未被框架解析，原始字符串可安全修改 - 不能依赖
c.Cookies()后遍历删除——那只是副本，Header 本身没变，后续中间件或 handler 仍会读到全部 Cookie - 正则提取键值对时，要处理分号分隔、空格、引号包裹（如
theme="dark"; path=/）、重复键等边界情况 - 白名单应只保留业务必需的 Cookie 名（如
session_id、locale），其余一律剔除；黑名单方式易漏，不推荐
为什么不能在 handler 里用 c.Cookie() 判断再丢弃
c.Cookie("name") 内部会触发一次完整的 http.Request.Cookies() 解析，该方法会把整个 Cookie 头一次性 parse 成 []*http.Cookie 切片并缓存到 req.Cookies 字段。一旦调用，就等于你已接受全部 Cookie —— 即使你只取其中一个，其余也早已进内存，无法“撤回”。
- 多次调用
c.Cookie()不会重复解析，但首次调用即完成全量加载 - 若你在中间件里写了
_, _ = c.Cookie("unknown_cookie")，哪怕只是试探性读取，也会导致所有 Cookie 被加载 - 更隐蔽的陷阱是：某些日志中间件或 JWT 鉴权中间件内部悄悄调用了
c.Cookies()，你没注意就已失守
如何安全地重写 Cookie Header 并保留合法项
核心是用 strings.Split 拆 c.Request().Header.Get("Cookie")，逐段解析 name=value，按白名单保留，再拼回标准格式。注意保留原始空格与分隔符规范，避免因格式错误导致浏览器忽略整个头。
- 用
strings.TrimSpace清理每段首尾空格，再用strings.SplitN(..., "=", 2)拆键值，防止 value 中含等号（如token=abc=def） - value 若带双引号（
"abc"），需手动去引号；若含转义（\x3B），通常可忽略——现代浏览器极少用，且攻击者伪造成本高 - 拼接时用
strings.Join(pairs, "; ")，确保分号后有空格，符合 RFC 6265 - 最后调
c.Request().Header.Set("Cookie", newCookieStr)替换原头；若结果为空字符串，可直接del c.Request().Header["Cookie"]
容易被忽略的兼容性与性能点
看似简单的一次字符串处理，实际在高并发下有隐性开销：每次请求都做字符串切分 + 分配 slice + 拼接，GC 压力明显。尤其当攻击者发送超长 Cookie 头（如 10KB+）时，可能成为 DoS 入口。
- 建议前置加长度限制：在该中间件最开头检查
len(c.Request().Header.Get("Cookie"))，超 4KB 直接c.NoContent(400) - 白名单列表建议用
map[string]struct{}存储，而非[]string遍历，O(1) 查找 - 不要在中间件里用
regexp解析 Cookie——编译开销大，且无必要；纯字符串操作足够安全准确 - 测试时务必覆盖
Cookie: a=1; b=2; c=3、Cookie: token="abc"; theme=light、Cookie:（空）等用例
真正起效的 Cookie 过滤，不是“删掉不想要的”，而是“只让想要的进来”。所有解析动作必须卡在框架自动解析之前，且 Header 重写必须完整、规范、带防御性长度校验。
