swag是go生态中唯一稳定落地的api文档自动生成方案，通过静态解析源码注释实现无需运行时反射的实时更新，但需严格遵循扫描路径、包声明、类型声明及结构体导出等硬性规范。
swag 是当前 Go 生态中唯一能稳定落地的 API 文档自动生成方案，其他工具要么不维护，要么扫不到真实项目结构。它不依赖运行时反射，而是静态解析源码注释——改一行注释，swag init 后文档立刻更新，无需重启服务。
swag init 扫不到接口？检查扫描路径和入口文件
执行 swag init 后 docs/swagger.json 中 paths 为空，或 Swagger UI 显示首页但无接口列表，问题几乎总出在“没扫到 handler 文件”。
-
swag init默认只扫描当前目录及子目录下属于同一 module 的.go文件；若 handler 分散在internal/handler、pkg/api等路径，必须显式指定：swag init -d internal/handler -d pkg/api - 入口文件（如
cmd/app/main.go）要用-g指定：swag init -g cmd/app/main.go，否则可能漏掉跨包注册的路由逻辑 - 被扫描的文件不能是
package main（除非它真包含r.GET()这类注册），推荐把路由逻辑单独放在package router或package api - 所有 handler 文件必须有合法
package xxx声明，且不能含语法错误，否则整个文件被跳过
@Param 和 @Success 写错类型？swag 不认 Go 类型系统
报错类似 cannot find type definition for "uuid.UUID" 或 unknown type "string"，本质是 swag 的类型解析器与 Go 编译器不一致：它只识别基础类型名和已用 // @Model 显式声明过的 struct。
-
@Param id path string true "用户ID"✅ —— 路径/查询/请求头参数只能用string、int、bool、float64，别写int64或uint -
@Param user body model.User true "用户信息"✅ —— 请求体（in: body）必须指向一个已定义的 struct，且该 struct 上方需有// @Model注释 -
@Success 200 {object} model.UserResponse✅ —— 结构体必须导出（首字母大写），字段必须带json:tag，否则字段不会出现在 schema 中 - 数组参数写法：
@Param ids query array true "ID列表" collectionFormat:multi items.type:string，不能简写为type: []string
中文乱码、响应体显示 “object”、字段全空？检查三个硬性条件
文档加载后中文变 \u4f60\u597d，或点开响应 schema 全是空对象，大概率不是配置问题，而是代码层面没满足 swag 的硬性要求。
- 源文件编码必须是 UTF-8（BOM 不可存在）
- struct 字段必须首字母大写（导出），且带有效
json:tag，例如Username string `json:"username"`；小写字段直接消失 - 不要用匿名 struct 或
map[string]interface{}作为@Success或@Failure类型，swag 解析不了运行时类型，会显示成空 schema
最容易被忽略的是：swag 不解析函数体，只靠注释块 + 类型推导。哪怕你用了 c.ShouldBindJSON(&req)，也必须显式写 @Param 和 @Success；哪怕结构体就在同一个文件里，没加 // @Model，swag 就当它不存在。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
