在生产环境中运行Go应用程序时，为什么建议使用`go build`而不是`go run`? [英] Why is it recommended to use `go build` instead of `go run` when running a Go app in production?

问题描述

我有一个Dockerfile，用于使用 go build 编译Go应用程序.我进行了研究，确实建议将 go build 用于生产.

I have a Dockerfile that I used to compile the Go app using go build. I researched and indeed go build is recommended for production.

但是我找不到关于为什么的正确答案.

However I cannot find a proper answer as to why.

我了解开始运行创建了一个临时文件，该文件将在应用终止时清除.但是，如果我使用的是Docker，为什么使用 go run 而不是 go build 不好?

I understand go run creates a temporary file that and that cleans up on app termination. But if I am using Docker, why is it bad to use go run instead of go build?

推荐答案

几个原因:

• Go应用程序不需要Go工具链，就像C应用程序不需要 gcc 一样.如果您使用 go build ，则只需部署二进制文件即可；如果您使用 go run ，则必须安装工具链.
• go run 每次运行时都不必要地编译应用程序，从而增加了启动时间.
• go run 将应用程序分叉到新进程，通过模糊PID和退出状态使进程管理不必要地复杂化.
当您仅打算运行应用程序时，
• 开始运行可能会意外吸收代码更改.仅当您想要一个新的二进制文件时才使用 go build ，您可以每次都重新运行相同，一致的二进制文件，而不会发生意外更改.

• A Go application does not require the Go toolchain, just as a C application doesn't require gcc. If you use go build, you can just deploy a binary; if you use go run, you have to install the toolchain.
• go run compiles the application unnecessarily every time it's run, increasing startup times.
• go run forks the application to a new process, making process management unnecessarily complicated by obscuring PIDs and exit statuses.
• go run has the potential to unexpectedly absorb code changes when you're only intending to run an application. Using go build only when you want a fresh binary allows you to re-run the same, consistent binary every time with no unexpected changes.

这篇关于在生产环境中运行Go应用程序时，为什么建议使用`go build`而不是`go run`?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！