在 Ubuntu 环境里编译 Go 项目，很多问题其实都不会藏得太深，关键是先把日志看全、看对。无论你是想确认 go build 是否成功，还是要继续追查依赖、编译链路和具体报错位置，都可以从不同层级的日志输出入手。下面按“从最直接到最详细”的顺序整理几种常用方法，方便你根据场景快速切换。
终端里直接看实时编译日志
最常见、也最直接的办法，就是在终端中进入项目目录后直接执行编译命令。比如先进入项目路径：
cd ~/go/src/myproject然后执行：
go build如果只编译指定文件，也可以写成：
go build main.go这时编译过程中的输出会直接显示在当前终端里，包括成功提示、警告和错误信息。对于日常开发来说，这通常就是第一步，因为它不需要额外配置，反馈也最快。
如果你只是想确认“这次打包有没有过”，或者先看一眼最明显的报错，这种方式已经足够。
日志太多时，先保存到文件再分析
当编译输出较多，或者你需要把日志留给后续排查时，更合适的做法是把标准输出和错误输出一起写入文件：
go build [目标文件] > build.log 2>&1这条命令里有两个关键点：
>：把标准输出（stdout）写入build.log；2>&1：把标准错误（stderr）也合并到同一个输出里，避免只保存了正常信息却漏掉真正的报错。
执行后，日志默认会保存在当前目录。查看时可以按自己的习惯选择工具：
cat build.log
less build.log
vim build.log如果你希望把日志放到固定目录，也可以直接指定完整路径：
go build > ~/logs/golang_build.log 2>&1这种方式适合两类场景：一类是日志内容太长，不适合在终端里回翻；另一类是需要把构建记录保留下来，便于重复比对或发给同事一起排查。
想看参与编译的包，用 -v 参数
如果终端里只有最终结果还不够，你想知道这次编译到底经过了哪些包，可以在 go build 后加上 -v：
go build -v [目标文件]例如：
go build -v main.go-v 是 verbose 模式，会输出参与编译的包名称和对应过程。它不只是“让日志变多”，更重要的是能帮助你判断问题大概落在哪一层：
- 如果某个包迟迟没有通过，可能说明依赖链上有问题；
- 如果你在排查构建变慢，也可以借它快速看出哪些包被重新编译了；
- 如果项目依赖较多，这个输出还能帮助你梳理实际参与构建的范围。
对于“构建没报明确错误，但过程不符合预期”的情况，-v 往往比默认输出更有参考价值。
想追到底层执行细节，用 -x 参数
再往下一层，如果你需要看到编译器和链接器到底执行了哪些命令，可以使用 -x 参数：
go build -x [目标文件]例如：
go build -x main.go这个输出会把每一步实际执行的命令打印出来，例如 # compile、# link 等阶段对应的底层调用。对一些表面上看不出来的问题，这类信息尤其有用，比如：
- 你怀疑错误出在编译阶段还是链接阶段；
- 你想确认 Go 工具链到底调用了哪些底层命令；
- 你需要定位某一步失败的准确位置，而不仅仅是看最后一条报错。
如果说默认输出适合“先看结果”，-x 更适合“顺着过程往下追”。在复杂问题上，它通常比单纯重复执行 go build 更有效。
不想切终端，也可以直接看 IDE 日志面板
如果你平时主要在图形界面里开发，也可以直接使用编辑器或 IDE 的输出面板查看编译日志。
VS Code
在 VS Code 中，可以点击顶部菜单栏 终端 → 输出，再选择 Go 或 编译 频道查看实时日志。
GoLand
在 GoLand 中，底部工具栏里的 Build 标签就会显示编译日志，打开后可以直接查看构建过程和报错信息。
这类方式的优势是操作门槛低，尤其适合刚接触 Go 或者更习惯图形界面的用户。不过一旦需要做日志重定向、比对多次构建结果，终端命令仍然更灵活。
使用时的两个判断点
最后再补两个容易忽略、但很实用的判断点。
日志文件保存位置可以自定义
如果没有单独指定路径，日志文件默认保存在当前目录；如果你有固定的日志归档习惯，可以直接改成诸如 ~/logs/golang_build.log 这样的路径。
成功和失败的日志信息量可能差很多
编译成功时，日志有时只会留下很简短的信息，例如类似“0 errors”的结果；而编译失败时，通常会明确指出错误原因，例如语法错误、依赖缺失等。实际排查时，可以先看是否失败，再决定要不要继续加上 -v 或 -x 深挖。
如果只需要一个简单结论，直接看终端输出即可；如果要保留记录，用重定向；如果要看包级过程，用 -v；如果已经进入底层排错阶段，就直接上 -x。按这个顺序切换，通常能更快找到问题所在。
