Context.JSONP()会自动终止响应，不能链式调用；必须前置校验callback合法性（正则匹配、非空、长度≤64）、数据可序列化，并禁用可能污染响应体的中间件，Nginx缓存需包含$args以避免callback混淆。
Context.JSONP() 会自动终止响应，不能链式调用其他方法
Echo 的 Context.JSONP() 不是普通响应方法，它内部调用 context.Response().WriteHeader() + write() + return（或 os.Exit(0) 级别拦截），执行后后续代码完全不执行。常见错误是写成：c.JSONP(200, data).SendString("done") 或在 JSONP() 后继续写日志、数据库操作——这些都会被跳过。
必须把它当作「最终响应语句」来用，且只能调用一次。如果需要前置校验，务必放在 JSONP() 调用之前：
- 先检查
c.QueryParam("callback")是否为空或非法（如含点号、斜杠、超长） - 再验证数据是否可 JSON 序列化（避免
json_encode()返回false） - 最后才调用
c.JSONP(200, data)
callback 参数必须白名单校验，否则存在 XSS 风险
Context.JSONP() 默认直接使用 c.QueryParam("callback") 值拼接 JS 函数调用，不做任何过滤。如果前端传入 ?callback=alert(1)，响应体就是 alert(1)({...})，浏览器执行后触发 XSS。
正确做法是严格限制 callback 名为合法 JS 标识符：
- 用正则
/^[a-zA-Z_][a-zA-Z0-9_]*$/校验，长度建议 ≤ 64 - 不接受空值、
null、undefined字符串（如" "或"//"） - 校验失败时应返回 HTTP 400，而不是静默 fallback 或输出空响应
示例校验逻辑：
cb := c.QueryParam("callback")
if cb == "" || !regexp.MustCompile(`^[a-zA-Z_][a-zA-Z0-9_]{0,63}$`).MatchString(cb) {
return c.String(400, "invalid callback name")
}
Content-Type 必须为 application/javascript，且不能被中间件覆盖
Echo 的 JSONP() 内部已设 Content-Type: application/javascript; charset=utf-8，但若你注册了自定义中间件（如日志、压缩、CORS），需确认它们没在 JSONP() 之后篡改 header。尤其注意 CORS 中间件：它通常对所有响应加 Access-Control-Allow-Origin，但 JSONP 响应本就不走 CORS 流程，加了反而冗余；更糟的是，某些中间件会在 write 之后强行追加 body（如模板渲染），导致响应变成 callback({...});...，JS 解析直接报错。
安全策略：
- 对 JSONP 路由单独禁用可能污染 body 的中间件（如
echo.MiddlewareFunc中判断 path 或 query） - 不要在 JSONP 路由里调用
c.Render()、c.HTML()或任何模板方法 - 若必须统一加 CORS 头，确保只在非 JSONP 请求中生效（比如检查是否存在
callback参数）
生产环境慎用 JSONP，Nginx 缓存易导致 callback 混淆
当 Echo 前挂 Nginx 且开启 proxy_cache 时，JSONP 响应极易被缓存为同一份——因为默认 cache key 不包含 query string。结果 A 用户请求 ?callback=a1，B 用户随后请求 ?callback=b2，却收到缓存的 a1({...})，前端执行时报 Uncaught ReferenceError: b2 is not defined。
必须在 Nginx 配置中显式把 callback 参数纳入缓存键：
proxy_cache_key "$scheme$request_method$host$request_uri$args";
注意末尾的 $args —— 它让每个不同 callback 值生成独立缓存项。漏掉这行，无论 Echo 怎么写都救不回来。
真正容易被忽略的点：JSONP 是 GET-only、无状态、无法携带 cookie 的方案，现代项目该用 CORS 就用 CORS；仅当对接遗留系统或 IE8/9 时才考虑 JSONP，且必须同步解决缓存、校验、终止控制三件事。
