应直接读取c.Request.Proto和c.Request.Method字段，前者返回"HTTP/1.1"等协议版本字符串，后者返回"GET"等大写方法名；不可调用不存在的c.Proto()或c.Method()，且c.Request.URL.Scheme为空，不能用于判断HTTP版本。
直接读 c.Request.Proto 和 c.Request.Method
Gin 的 *gin.Context 本身不提供独立的协议版本或方法字段，它把底层 *http.Request 完全暴露在 c.Request 上。所以不用找封装方法，直接取原始字段就行。
常见错误是试图调用 c.Proto() 或 c.Method() —— 这些函数根本不存在，Go 会报 undefined 错误。
-
c.Request.Proto返回字符串，如"HTTP/1.1"或"HTTP/2.0" -
c.Request.Method返回大写字符串，如"GET"、"POST"、"PUT" - 这两个字段在请求生命周期内恒定，无需额外解析或缓存
为什么不能用 c.Request.URL.Scheme 判断 HTTP 版本
c.Request.URL.Scheme 是空的 —— 标准 net/http 不会从原始请求行里提取 scheme，它只负责解析 Host、Path、RawQuery 等。Scheme 通常由反向代理（如 Nginx）通过 X-Forwarded-Proto 注入，属于应用层约定，不是协议本身字段。
如果你真需要判断是否为 HTTPS，应该检查：
-
c.Request.TLS != nil（表示 TLS 连接已建立） - 或读取
c.GetHeader("X-Forwarded-Proto")，但必须信任上游代理 - 别混淆
Proto（HTTP/1.1）和ProtoMajor/ProtoMinor（整数版，如 1 和 1）—— 后者更底层，一般没必要用
实际使用中要注意的边界场景
某些网关或测试工具（如旧版 Postman、curl 无 -v）可能发送非法请求行，导致 c.Request.Proto 为空或格式异常（比如 "HTTP//1.1"）。生产环境建议加一层校验：
proto := c.Request.Proto
if proto == "" || !strings.HasPrefix(proto, "HTTP/") {
proto = "HTTP/1.1" // fallback
}
另外，c.Request.Method 虽然可靠，但注意它不校验 RFC 合法性 —— 如果客户端发了 MEOW / HTTP/1.1，Go 仍会把它原样塞进 Method 字段，后续路由匹配会失败（405），但字段读取本身不会 panic。
结合日志与调试的典型写法
在中间件或 handler 开头快速打点时，推荐一行式结构化输出：
log.Printf("[%s] %s %s %s", c.ClientIP(), c.Request.Method, c.Request.URL.Path, c.Request.Proto)
注意这里没用 c.Request.URL.String()，因为它拼出来的 URL 包含 RawQuery，可能含敏感参数；路径用 Path 更安全。如果要记录完整请求行（调试用），可手动拼：c.Request.Method + " " + c.Request.URL.RequestURI() + " " + c.Request.Proto。
真正容易被忽略的是：这些字段在 c.Request.Body 被读取后依然有效 —— 因为它们来自请求头行，不依赖 body 流。但别反过来假设 body 可重复读，那得靠 c.Request.Body 的重放机制（如 c.ShouldBindJSON 内部已处理）。
