APISIX 是独立于 Go 微服务的语言无关 API 网关，部署在集群前端作为统一入口，Go 服务仅需标准 HTTP 暴露接口（如 :8080），由 APISIX 通过 Kubernetes Service（如 user-svc:8080）转发请求，不嵌入、不依赖、不共进程，且 APISIX pod 不注入 Linkerd sidecar。
APISIX 不是 Go 微服务的一部分，它是一个独立的、语言无关的企业级 API 网关。你不需要“在 Golang 微服务中部署 APISIX”，而是把它部署在微服务集群前面，作为统一入口，让 Go 服务专注业务逻辑。
真正的部署关系是：客户端 → APISIX（南北向）→ Kubernetes Service → Go Pod（带或不带 Linkerd sidecar）。Go 服务本身不嵌入、不启动、不依赖 APISIX。
APISIX 必须独立部署，不能跑在 Go 进程里
常见误解是把 APISIX 当成 Go 的一个库或中间件来 go get 引入——这完全错误。APISIX 是基于 Nginx + Lua 的独立进程，底层依赖 etcd 或 consul 存配置，Go 服务只负责提供 HTTP 接口，其余由网关接管。
-
APISIX启动后监听:9080（proxy）和:9180（admin），它不读你的main.go，也不调用你的http.HandlerFunc - Go 服务只需按标准 HTTP 方式暴露（如
:8080），确保能被APISIX通过 Service DNS 或 IP 访问到 - 若你在本地用
kind，Go 服务要部署在同一个集群内，并打上linkerd.io/inject: enabled标签（如需 mTLS）
Go 服务如何与 APISIX 协同工作
关键不是“集成”，而是“约定”：Go 服务暴露的路径、Header、状态码，要和 APISIX 路由/插件规则对齐。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
APISIX路由匹配/api/v1/users→ 转发到http://user-svc:8080/v1/users，Go 服务必须真实响应该路径，不能只实现/users - JWT 验证由
APISIX的jwt-auth插件完成，Go 服务无需解析 token；但需从X-Forwarded-User或X-Consumer-ID读取认证后身份 - 限流、熔断、日志、追踪都由
APISIX插件处理，Go 服务日志只需记录业务事件，不用管 QPS 或失败率 - 如果用了
Linkerd，APISIXpod **不能注入 sidecar**（官方明确要求），否则 mTLS 会干扰其 upstream 连接
配置 APISIX 路由时，Go 服务地址怎么填
填的是 Kubernetes Service 名（推荐），不是 Pod IP，更不是 localhost。
- 在
kind或生产集群中，Go 服务部署后生成 Service，比如user-svc，端口8080 - 创建
Upstream时，nodes字段应写"user-svc:8080"，而非"10.244.0.12:8080"（Pod IP 不稳定） - 若用 Helm 安装
APISIX，确保values.yaml中networkPolicy.enabled=false（默认 true，会阻断跨 namespace 访问） - 验证方式：
kubectl exec -it -n apisix deploy/apisix -- curl -v http://user-svc:8080/healthz，通则路由可配
为什么本地开发常踩坑：APISIX 找不到你的 Go 服务
根本原因不是代码写错，而是网络或 DNS 层不通。
-
APISIXpod 默认在apisixnamespace，Go 服务若在defaultnamespace，需用全限定名user-svc.default.svc.cluster.local:8080 - Docker Desktop 或 Kind 的
/etc/hosts不影响集群内 DNS，别试图 host 映射 - 检查
kubectl get endpoints user-svc是否有可用 endpoint；空列表说明 Deployment 没 ready 或 selector 不匹配 -
APISIXadmin API 返回500且 log 出现failed to resolve upstream，基本就是 DNS 或 Service 问题
真正要花时间调试的，从来不是 Go 代码里的 router.GET，而是 APISIX 的 upstream_id 是否指向正确的 Service、route.uri 是否与 Go handler 路径严格一致、以及 Kubernetes Service 的 port 和 targetPort 是否对得上。这些地方一错，请求连网关层都进不去。
