先说几个核心判断：浏览器不能直接调用 gRPC，这不是配置层面的问题，而是协议层本身的硬限制——HTTP/2 + Protobuf 与 HTTP/1.1 + JSON 之间的鸿沟，不是靠改几个参数就能跨越的。想让前端直连 Go 后端的 gRPC 服务，必须加一层 gRPC-Web 网关来承担协议转换。这不是可选组件，而是必经通路。
为什么是 Envoy 而不是 grpcwebproxy
可能有人会问，grpcwebproxy 不是也能用吗？但问题在于，它已经归档、不再维护了。本地跑个 demo 或许还能凑合，一上生产就容易露馅：没有 TLS 终止、没有健康检查、没有可观测性集成。Envoy 才是唯一靠谱的选择，尤其是在 Kubernetes 场景下。
实践中有几个关键点需要留意：
envoy.filters.http.grpc_web必须显式启用，否则浏览器发application/grpc-web+proto请求时，会静默返回415 Unsupported Media Type- Envoy 默认不转发 CORS 头，前端预检（
OPTIONS）会直接失败。需要在http_filters里配置envoy.filters.http.cors，或者交由后端处理 - 如果用
docker-compose部署，Envoy 容器要能访问 Go gRPC server 的0.0.0.0:9090，不能绑127.0.0.1——在容器网络里，localhost指的是自己
Go gRPC server 需要改什么
好消息是，业务代码完全不用动。但有两个隐性条件必须满足，否则网关转不动：
- 必须启用反射：
reflection.Register(server)，否则前端调试工具（如grpcurl或 Web UI）查不到服务列表 - 监听地址必须是
0.0.0.0:9090，不能是127.0.0.1:9090；否则 Envoy 在另一容器里根本连不上 - CORS 头建议由网关统一加（Envoy 支持），如果非要后端加，得用拦截器写
w.Header().Set("Access-Control-Allow-Origin", "*")，且注意Access-Control-Allow-Headers至少包含content-type和x-grpc-web
前端怎么调用才不报错
生成的 JS 客户端桩（protoc-gen-grpc-web 输出）默认走 http://localhost:8080（grpcwebproxy 的默认端口），但你用的是 Envoy，所以需要手动指定网关地址：
- 初始化 client 时传入
host参数：new MyServiceClient("http://your-envoy-host:10000") - 流式 RPC（server-stream / bidi）需要确认 Envoy 配置启用了
stream_idle_timeout，否则连接空闲 60s 后会自动断开，前端onEnd会收到status.UNKNOWN - 不要用
fetch手动拼请求——gRPC-Web 的协议头（如Content-Type: application/grpc-web+proto）和帧格式（length-delimited）非常严格，手写极易出错
最容易被忽略的一个点是：Envoy 的 grpc_web filter 只识别特定的 MIME 类型，而前端生成的 client 默认发的是 application/grpc-web+proto。如果后端 proto 编译时用了 --grpc-web_out=import_style=commonjs+dts,mode=grpcweb，但 Envoy 没配对这个类型，就会卡在 415。这个点不排查，其他配置都白搭。
