不能。gRPC原生不支持JSON/HTTP接口，需通过gRPC-Gateway添加转换层；必须在.proto中添加google.api.http注解（如post: "/v1/messages" body: "*"），并同时生成gRPC stub与HTTP handler，启动两个服务，无法跳过注解或自动映射。
gRPC服务如何不改.proto就暴露JSON/HTTP接口
不能。gRPC原生协议是基于HTTP/2的二进制传输，grpc-go、grpc-java等官方实现默认不解析JSON请求体，也不自动生成REST路由。所谓“不修改协议直接支持”，本质是加一层转换层，而非gRPC自身能力。
用gRPC-Gateway实现JSON/HTTP到gRPC的透明转发
这是最常用、也最接近“不改.proto”的方案：在gRPC服务旁启动一个反向代理，把/v1/some/path这类REST请求，按预定义规则映射成gRPC调用。关键在于.proto里加google.api.http注解，不是完全不改，而是只改注释不改消息结构和方法签名。
- 必须引入
google/api/annotations.proto并import - 每个
rpc方法上方加option (google.api.http) = {post: "/v1/messages" body: "*"}这类声明 - 生成代码时需同时跑
protoc生成gRPC stub +protoc-gen-grpc-gateway生成HTTP handler - 启动时要同时起gRPC server和gateway server（后者作为独立HTTP/1.1服务）
示例注解：option (google.api.http) = {get: "/v1/users/{name}"}; → 自动从URL path提取name字段填入request message
为什么不能跳过注解直接“自动映射”
因为gRPC没有URI路径、HTTP方法、查询参数这些概念，而REST依赖它们。没有google.api.http注解，gateway无法知道：ListUsers该对应GET /users还是POST /users:list？分页参数放query还是body？id字段该从path取还是从JSON body取？
- 不写注解 → gateway生成空路由或报错
no HTTP rule found - 注解写错（比如
body: "user"但message里没user字段）→ 请求时返回400 Bad Request且无明确提示 - 忽略
body: "*"和body: "id"区别 → 前者把整个JSON当message，后者只取JSON中id字段赋值，其余丢弃
性能与部署实际影响
gateway是独立进程或goroutine，每次REST请求会多一次HTTP解析+JSON反序列化+gRPC序列化+网络调用，延迟比直连gRPC高1–3ms（本地环境），吞吐下降约20–40%。线上务必让gateway和gRPC backend走localhost或同一AZ内网。
- 不要把gateway和gRPC server打包进同一个二进制再用
net/http复用端口 —— 它们协议不兼容，强行混用会导致HTTP/2连接被gRPC server拒绝 - gateway默认不校验JWT，需要手动集成
runtime.WithForwardResponseOption或中间件 - gRPC服务升级时，gateway的
.proto必须同步重新生成，否则新字段不会出现在JSON响应里
真正省事的点只有一个：不用重写业务逻辑，但注解、生成步骤、双服务部署，一个都绕不开。
