Kong无需在Go服务中接入，而是作为独立反向代理层部署在其前端；Go服务只需暴露标准HTTP接口、监听可被Kong访问的地址（如0.0.0.0:8081）、正确解析X-Forwarded-User等Kong注入头，并避免响应Location指向内网地址。
直接结论：Kong 不需要在 Go 服务里“接入”，它独立运行，Go 服务只需暴露标准 HTTP 接口
很多人误以为要在 Go 服务代码里写一堆 Kong SDK 或配置注入逻辑——其实完全不需要。Kong 是一个独立的反向代理层，部署在 Go 微服务之前，所有流量先经 Kong 路由、鉴权、限流，再转发到你的 http.ListenAndServe 服务。Go 服务本身只管处理业务，保持无状态、无 Kong 依赖。
Kong 启动后，Go 服务要改什么？
几乎不用改，但有三个硬性前提必须满足：
- Go 服务监听地址必须可被 Kong 访问（比如
0.0.0.0:8081，不能是127.0.0.1:8081） - 响应头中不要手动设置
Location为内网地址（如http://localhost:8081/login），否则 Kong 不会重写，前端会跳转失败 - 若用 JWT 鉴权，Go 服务需从
X-Forwarded-User或X-Consumer-Username（Kong 插件注入）读取用户身份，而不是解析原始 Authorization 头——因为 Kong 可能已校验并剥离 token
用 Kong Admin API 注册 Go 服务时的关键字段
调用 POST /apis 或新版 POST /services 时，以下参数直接影响转发是否成功：
-
url或host+port：必须填 Go 服务实际监听的内网地址，如http://user-srv:8081（Kubernetes Service 名）或http://10.20.30.40:8081 -
uris：定义匹配路径前缀，例如[ "/user/" ]，注意末尾斜杠——Kong 默认不自动补，/user和/user/是不同路由 -
strip_path：设为true时，Kong 会把匹配的前缀（如/user/）从请求路径中移除再转发，Go 服务收到的就是/profile而非/user/profile -
retries：建议设为2，避免单点网络抖动导致 502；Kong 默认只试 1 次
Go 服务日志里为什么总看到 127.0.0.1？
因为 Kong 默认把请求发给上游时，RemoteAddr 是它自己的 loopback 地址。要拿到真实客户端 IP，必须：
立即学习“go语言免费学习笔记（深入）”；
- 在 Kong 中启用
real-ip插件，并配置trusted_addresses（如负载均衡器 IP 段） - Go 服务里别直接用
r.RemoteAddr，改用r.Header.Get("X-Real-IP")或r.Header.Get("X-Forwarded-For")（注意后者可能被伪造，需结合可信段校验） - 如果用了
gin，可用c.ClientIP()——它已内置了对这些头的优先级解析和信任链校验
漏掉这一环，所有限流、风控、审计日志里的 IP 都会错，且无法回溯真实来源。
