能共存，需确保路由前缀不冲突、注册顺序合理（先GraphQL后REST）、中间件手动桥接、共享service层而非handler、resolver严格使用传入ctx并避免goroutine泄漏。
GraphQL 和 REST 路由能共存于同一个 Gin/Chi 服务里吗？
能，而且很常见——只要路由前缀不冲突、中间件不互相干扰。关键不是“能不能”，而是“谁处理请求更早、谁负责错误兜底”。
常见错误现象：404 看似随机出现，其实是 GraphQL 的 /graphql 被 REST 的通配路由（比如 /:id 或 /*path）提前捕获了；或者两者都注册了 POST /graphql，但 Gin 的 router.POST 和 graphql-go/handler 的 handler.GraphQL 没对齐方法或 Content-Type 处理逻辑。
- REST 接口建议用明确路径，如
/api/v1/users；GraphQL 统一走/graphql，别改成/api/graphql——多数客户端 SDK 默认认这个路径 - Gin 中注册顺序很重要：先注册
router.POST("/graphql", graphqlHandler)，再注册 REST 路由；否则router.Any("/*path", fallbackHandler)会吞掉所有未匹配请求 - GraphQL handler 必须显式检查
Content-Type：只响应application/json或application/graphql，避免被表单提交或浏览器直连触发非预期行为
gqlgen 生成的服务怎么和现有 HTTP 中间件兼容？
gqlgen 本身不走标准 HTTP 中间件链，它的 graphql.Handler 是个独立的 http.Handler，所以 Gin/Chi 的 Use() 对它无效。必须手动桥接。
使用场景：你已有 JWT 验证中间件、请求日志、跨域配置，想复用到 GraphQL 请求上。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 不要把 gqlgen handler 直接塞进
router.POST；改用router.Any("/graphql", adaptGQLHandler(graphqlHandler)) -
adaptGQLHandler是个包装函数：先执行你的鉴权逻辑（比如从r.Header.Get("Authorization")提取 token），再把*http.Request和http.ResponseWriter透传给 gqlgen handler - 注意 context 传递：gqlgen 的
graphql.Resolver依赖ctx，务必用r = r.WithContext(context.WithValue(r.Context(), key, value))注入用户信息，而不是靠中间件隐式挂载
同一份数据库模型，怎么让 REST 和 GraphQL 共享数据层又不耦合？
直接共享 struct 定义没问题，但别让 GraphQL 的 Resolver 直接调用 REST 的 handler 或 vice versa。核心是分清职责：数据获取统一走 service 层，序列化格式由上层决定。
参数差异体现在：REST 接口常需分页参数 limit/offset，GraphQL 用 first/after；时间字段可能一个返回字符串、一个返回 Unix 时间戳。
- 定义统一的 service 接口，比如
UserSvc.FindByID(ctx context.Context, id string) (*User, error)，REST handler 和 Resolver 都调它 - GraphQL 的
User类型字段名要和 resolver 返回值严格对应，别指望自动映射；CreatedAt字段在 resolver 里得显式转成time.Time或字符串，不能依赖 struct tag 里的json:"created_at" - 避免在 resolver 里做权限判断——该逻辑应前置到 HTTP 层（比如通过 context 注入当前用户角色），否则 REST 和 GraphQL 权限校验会不一致
并发下 GraphQL 的 context.Context 生命周期容易出什么问题？
GraphQL 执行时会为每个字段启动 goroutine，但默认的 context.Background() 或未带 timeout 的 request context 会导致超时控制失效、数据库连接泄漏、日志上下文丢失。
性能影响明显：一个慢查询拖垮整个连接池，而 REST 接口可能已设了 ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second)。
- gqlgen 的
graphql.Config中必须设置Tracer和Recover，否则 panic 会直接 kill 整个 handler - resolver 函数签名必须是
func() (string, error)这类形式，别在闭包里捕获外部context.Context——它可能已被 cancel - 数据库查询一律用传入的
ctx，比如db.QueryRowContext(ctx, ...)；别用db.QueryRow(...)，否则 timeout 不生效
最常被忽略的是 resolver 内部的 goroutine 没继承父 ctx，比如用 go func() { ... }() 启动异步操作却不传 ctx，结果父请求超时了，子 goroutine 还在跑。
