#开发模式启动

Go 后端项目在开发阶段常见有两种启动方式：

• 手动启动：修改代码后，自己重新执行命令。
• 使用 Air：监听文件变化，自动重新编译和重启服务。

本文以 Gin 后端项目为例，介绍这两种方式。

#方式 1：手动启动

手动启动最简单，不需要额外工具。

如果只是启动项目，可以直接执行：

go run .

go run . 会临时编译当前目录下的 Go 程序，并直接启动服务。

也可以是手动的先编译成二进制，再手动的启动：

go build -o ./tmp/main .
./tmp/main

如果希望把 Swagger 生成、编译和启动串起来，可以这样写：

swag init -g utils/docs-meta.go  && go build -o ./tmp/main . && ./tmp/main

这里的 && 表示：前一个命令执行成功后，才会继续执行下一个命令。

所以这条命令的执行顺序是：

生成 Swagger 文档 -> 编译 Go 项目 -> 启动编译后的服务

手动启动的问题是：每次修改 Go 代码后，都需要自己停止服务，然后重新执行启动命令。

#方式 2：使用 Air

Air 是 Go 项目常用的热重载工具。它会监听文件变化，当你修改 .go 文件后，自动重新编译并重启服务。

#安装 Air

go install github.com/air-verse/air@latest

安装完成后，可以检查是否可用：

air -v

如果提示找不到 air 命令，需要确认 Go 的 bin 目录是否已经加入环境变量。

常见路径是：

$(go env GOPATH)/bin

#初始化配置

在项目根目录执行：

air init

执行后会生成一个配置文件：

.air.toml

后续 Air 会根据这个配置文件来决定监听哪些文件、执行什么编译命令、启动哪个二进制文件。

#启动项目

在项目根目录执行：

air

启动后，Air 会监听项目文件变化。

当你修改 Go 代码并保存后，Air 会自动：

停止旧服务 -> 重新编译 -> 启动新服务

这样开发时就不需要每次手动停止和重启后端服务。

#配置 Swagger 生成

如果你的项目每次启动前都需要执行 swag init，可以在 .air.toml 里配置构建命令。

示例：

[build]
cmd = "swag init -g utils/docs-meta.go -d ./ --pd && go build -o ./tmp/main ."
bin = "./tmp/main"

这样每次文件变化后，Air 会先重新生成 Swagger 文档，再重新编译并启动服务。

如果你的 Swagger 注释已经放在默认入口 main.go 上，也可以省略 -g：

[build]
cmd = "swag init -d ./ --pd && go build -o ./tmp/main ."
bin = "./tmp/main"

如果项目不需要 Swagger，可以只保留编译命令：

[build]
cmd = "go build -o ./tmp/main ."
bin = "./tmp/main"

#两种方式对比

手动启动：
优点：
1. 不需要安装额外工具。
2. 命令直观，适合刚开始理解项目启动流程。
3. 出问题时更容易判断是哪一步失败。

缺点：
1. 每次修改代码后，都需要手动重启。
2. 开发效率低，频繁改代码时比较麻烦。
3. 如果启动前有 Swagger、编译等多个步骤，命令会越来越长。

使用 Air：
优点：
1. 修改代码后自动重新编译和重启服务。
2. 适合日常开发，效率更高。
3. 可以把 Swagger 生成、编译、启动流程统一写进 .air.toml。

缺点：
1. 需要额外安装 Air。
2. 需要维护 .air.toml 配置。
3. 如果监听范围过大，可能会因为无关文件变化频繁重启。

#总结

刚开始熟悉项目时，可以先使用手动启动：

go run .

或者：

go build -o ./tmp/main .
./tmp/main

这样更容易理解项目到底是怎么编译和启动的。

日常开发时，更推荐使用 Air：

air

它可以自动监听代码变化并重启服务，减少重复操作。

如果项目里还需要生成 Swagger 文档，可以把 swag init 写进 .air.toml 的 cmd 里，让整个开发启动流程自动化。