空格 OR 逗号 AND 感叹号 NOT 换行 AND
按照官网的例子来说明下
// +build linux,386 darwin,!cgo
对应的逻辑运算：
(linux AND 386) OR (darwin AND (NOT cgo))
// +build linux darwin
// +build 386
对应的逻辑运算：
(linux OR darwin) AND 386
对应的条件可以有如下值：
操作系统, 值可以通过 runtime.GOOS 获取，比如 linux
CPU架构, 值可以通过 runtime.GOARCH 获取 ， 比如 amd64 编译器，如 gc, gccgo
是否开启Cgo， cgo
语言版本, Go版本如 go1.1,…,go1.12
自定义标签, 任意标签，可以是发布版本号，开发版本等等， 比如生产环境prod
在实际开发中，一般正常的商业项目都会区分开发环境、测试环境、灰度验证环境、正式环境。那么这么多环境，数据源，redis，日志级别等的配置一般也不一样。如何保证在不同的环境使用不同的配置呢。
1、 启动时 指定配置文件
编译后的可执行文件在目标环境执行时，可以通过指定参数的方式来确定执行环境，读取的配置文件。
假设编译后的执行文件名为 server, $exec_path为可执行文件所在路径，比如/usr/local
开发调试环境
$exec_path/server debug
线上正式环境
$exec_path/server prod
如果使用这种方式就需要在代码里判断传递的参数，然后使用对应的配置。编写文件server.go如下
package main
import (
"fmt"
func main() {
serverMode := os.Args[1]
switch serverMode {
case "debug":
// 加载调试模式配置
fmt.Printf("传递模式为%s，加载调试模式配置\r\n", serverMode)
case "prod":
// 加载正式环境配置
fmt.Printf("传递模式为%s，加载正式环境配置\r\n", serverMode)
default:
panic("启动模式错误")
go build server.go
./server debug
#输出如下
传递模式为debug，加载调试模式配置
2、 通过 环境变量
设置环境变量(linux环境)
export SERVER_MODE=‘debug’
在代码里读取变量，然后可以按照读取的值加载不同的配置。代码处理与1中传递启动参数类似。
os.Getenv(“SERVER_MODE”)
3、 编译时 使用ldflags
编写config.go内容如下
package main
import "fmt"
var mode string
func main() {
fmt.Println("mode value is:", mode)
go build -ldflags ‘-X main.mode=prod’ config.go
./config
mode value is: prod
既然编译时可以确定mode的值，那么想要根据mode加载不同的配置，那么就轻而易举的解决了。
4、 使用条件编译 分别编写config_prod.go 和 config_dev.go 分别代表生产环境和开发环境的配置。 项目布局如下
├── config
│ ├── config_dev.go
│ └── config_prod.go
└── main.go
config_prod.go
//+build prod
package config
var String = "this is prod mode"
var String2 = "prod test"
func Config() string {
return String2
config_dev.go
//+build dev
package config
var String1 = "this is debug mode"
var String2 = "debug test"
func Config() string {
return String2
main.go
package main
import (
"config"
"fmt"
func main() {
fmt.Println("this build is: ", config.String1, config.String2, config.Config())
编译(-o 指定编译后生成的可执行文件名)
go build -tags prod -o main
./main
this build is: this is prod mode prod test prod test
可见使用这种方式也达到了不同环境使用不同配置的目的。实际项目开发中，根据项目规划需要来选择。
编译标签 （build tag）
在源码文件顶部添加注释，来决定文件是否参与编译
// +build
golang
以空格分开表示AND
以逗号分开表示OR
!表示NOT
标签可以指定为以下内容：
操作系统，环境变量中GOOS的值，如：linux、darwin、windows等等。
操作系统的架构，环境变量中GOARCH的值，如：arch64、x86、i386等等。
使用的编译器,gc或者gccgo。
是否开启CGO,cgo。
golang版本号： 比如Go Version 1.1为go1.1,Go Version 1.12版本为go1.12，以此类推。
其它自定义标签，通过go build -tags指定的值。
例如，编译条件为(linux AND 386) OR (darwin AND (NOT cgo))
// +build linux,386 darwin,!cgo
golang
另外一个文件可以有多个编译约束,比如条件为(linux OR darwin) AND amd64
// +build linux darwin
// +build amd64
golang
也可以将一个文件从编译中排除，使用ignore标签。
// +build ignore
golang
注意：// +build的下一行必须是空行。
// +build linux
// main package comment
package main
golang
下面的写法不会识别为build tag，而会解析为包注释：
// +build linux
package main
golang
除了编译标签，编译器也会根据文件后缀来自动选择编译文件，格式如下:
$filename$GOOS.go
$filename$GOARCH.go
$filename$GOOS$GOARCH.go
$filename: 源文件名称。
$GOOS: 表示操作系统，从环境变量中获取。
$GOARCH: 表示系统架构，从环境变量中获取。
如在项目中有tcp.go和tcp_linux_x86.go 两个文件，执行:
GOOS=linux GOARCH=x86 go build
将选择 tcp_linux_x86.go进行编译，而执行:
GOOS=linux GOARCH=x86 go build
选择tcp.go进行编译。
利用ldflags在编译过程中为变量赋值
本节为附加说明，不属于条件编译的范畴。有时我们需要在编译过程中为变量赋值，此时可以利用ldflags参数完成。ldflags是go build的一个参数，使用方式如下：
go build -ldflags “-w -s -X main.Version=${VERSION} -X github.com/demo/version.BuildNo=${BUILD_NO}”
参数说明：
-w 删除DWARF信息：编译出来的程序无法用gdb进行调试。
-s 删除符号表：panic的stack trace没有文件名/行号信息，等价于C/C++程序被strip。
-X 替换包中的变量的值。
加上-w -s可以有效减少编译出来地程序的大小，但不利于进行调试和日志追踪。
今天继续关于Go开发经验的分享，这次的主题是关于Go的交叉编译和条件编译，伴随着我对自己打不过、惹不起的壕同事小张还有运维们的碎碎念。
交叉编译是用来在一个平台上生成另一个平台的可执行程序。比如我工作开发时用的Mac，系统内核是darwin，小张用的是外星人，系统内核是windows （小张明显比我有钱，我的Mac是公司发的，人家的外星人是为打游戏自己买的）。
那么假如我编写的代码依赖了系统底层平台或处理器架构特性的Go包时，比如说我上周在文章《Go服务迁到K8s后老抽风重启? 记一次完整的线上问题解决过程》里写的，为了把Go运行时的panic错误重定向到日志文件，我用了syscall.Dup2这个函数把标准错误原来的文件描述符替换成了自己指定的日志文件的描述符。syscall.Dup2是Go语言在类Unix系统，X86_64架构下才有的函数库，在Mac系统上、各种服务器环境上编译都没有问题，但是唯独在像小张这样不用办公电脑的土豪们用的Windows系统上编译不过去。
所以在上篇文章说的那个为了追踪在Kubernetes上服务老重启的问题，用syscall.Dup2重定向标准输出的解决方案是有副作用的，我贴一下之前这个功能的代码。
func RewriteStderrFile() error {
if runtime.GOOS == "windows" {
return nil
......
file, err := os.OpenFile(stdErrFile, os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666)
if err != nil {
fmt.Println(err)
return err
if err = syscall.Dup2(int(file.Fd()), int(os.Stderr.Fd())); err != nil {
fmt.Println(err)
return err
......
return nil
天真的用了一个runtime.GOOS == “windows”的判断，我还想着能在代码里根据内核的不同执行不同的代码，但是Go的软件包是先编译成可执行文件再执行的，这个判断根本没啥用。所以在Windows系统下编译项目的时候，因为没有syscall.Dup2直接就失败了……。
我这不就是典型的动态语言的思维吗，之前还写文章跟别人讲《如何避免用动态语言的思维写Go代码》……这次打自己脸打的实在有点疼。
虽然项目这个更新已经上线了，但是土壕小张和运维我都惹不起，迫于无奈我就看了看Go官方的标准库到底是怎么兼容多平台的。
网管瞎吐槽：我真觉得像在Kubernetes收集服务的错误日志这事儿该运维想办法干……，从公司基础设施建设层面，统一化收集所有rpc服务的错误日志，这样所有服务的代码都不用改，比我自己在项目里加代码不强吗？你们觉得我说的对不对（是不是能少干活…）。
我发现在go的每个内置库里都有很多以不停系统名结尾的文件。下面是Go的os[1]内置库源代码的部分截图：
在有些文件里还有类似下面这样的注释：
// +build aix darwin dragonfly freebsd js,wasm linux netbsd openbsd solaris
package os
看了些资料后才知道，他们是用于Go软件包的条件编译[2]的，条件编译的意思就是通过某种方式来指示编译器编译特定代码。
Go不支持宏，不可以像c语言那样使用#define来控制是否包含平台相关的特定代码。作为替代，Go使用构建标签(build tags)和代码文件的命名约定来支持Go软件包的条件编译。
构建标签就是上面我说的源代码里的注释：
// +build aix darwin dragonfly freebsd js,wasm linux netbsd openbsd solaris
package os
需要注意的是，构建标签必须在代码文件里位于package声明的上方，并且后跟一个空行。
当Go编译一个包时，它会分析包内的每个源码文件并查找构建标签。标签决定了这个源码文件是否被编译。
构建标签遵循以下三个原则：
空格隔开的选项是或（OR）的关系
逗号隔开的选项是与（AND）的关系
每个选项由字母和数字组成。如果前面加上!，则表示反义
// +build darwin freebsd netbsd openbsd
上面的例子，表示这个源码文件只会在支持kqueue的BSD系统中被编译。
一个源码文件可以包含多个构建标签。构建规则是每个独立规则的逻辑与关系。如下例子表示该文件将在linux/386或darwin/386平台才会被编译 。
// +build linux darwin
// +build 386
用逻辑表达式表示就是：(linux OR darwin) AND 386。
文件名后缀
第二种条件编译的方法是通过源码文件的文件名实现的。这种方案比构造标签方案更简单。
go/build包的文档有关于命名约定的描述。简单来说，如果文件名包含_Missing superscript or subscript argumentGOARCH.go。这两种后缀可以组合起来，但要保证顺序，正确的格式是_Missing superscript or subscript argumentGOARCH.go，错误的格式是_Missing superscript or subscript argumentGOOS.go。
以下是文件名后缀的一些例子：
mypkg_freebsd_arm.go // 只在 freebsd/arm 系统编译
mypkg_plan9.go // 只在 plan9 编译
mypkg_darwin.go // 只在macos 系统编译
源码文件光有后缀是不行的，比如如下文件名：
_linux.go
_freebsd_386.go
即使是在Linux或FreeBSD系统，这两个文件也会被忽略，原因是go/build包会忽略所有文件名以.和_开始的文件。
使用构建标签还是文件名后缀
构建标签和文件名后缀在功能上是重叠的。比如，一个名为mypkg_linux.go的文件，再包含构建标签// +build linux会显得多余。
通常来说，当只有一个特定平台或体系需要指定时，我们选择文件名后缀的方式。比如：
mypkg_linux.go // 只在 linux 系统编译
mypkg_windows_amd64.go // 只在 windows amd 64位 平台编译
相反，如果你的文件需要指定给多个平台或体系架构使用，或者你需要排除某个特定平台时，我们选择构建标签的方式。比如：
// 在所有类unix平台编译
// +build darwin dragonfly freebsd linux netbsd openbsd
// 在非Windows平台编译
// +build !windows
应用环境，我就说下是怎么解决文章开头说的问题让小张大佬平复心情的吧……。
设置条件编译
首先我像下面这样，在包里建了两个源码文件，用来分别存放在Windows系统和非Windows系统下使用的RewriteStderrFile函数：
project
└───pkg1
│ │----rewrite_err_unix.go
│ │----rewrite_err_windows.go
因为我们的项目在那几个大佬电脑的Windows系统上编译和运行的时候都是开发阶段，其他测试上线之类的环境都是Linux系统，所以我懒癌发作，直接写了个空函数，毕竟只要能编译运行小张就不会太难为我了。
//rewrite_err_windows.go
package pkg1
func RewriteStdErrLog(topic string) error {
return nil
对于要在服务器上和Mac电脑上编译的源码，跟之前的差不多，只是增加了构建标签：
//+build darwin linux
package pkg1
......
func RewritePanicsToFile(topic string) error {
......
file, err := os.OpenFile(stdErrFile, os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666)
if err != nil {
fmt.Println(err)
return err
if err = syscall.Dup2(int(errFileHandler.Fd()), int(os.Stderr.Fd())); err != nil {
return err
......
return nil
执行交叉编译
交叉编译的执行就非常简单了，在编译时给go build命令设置OS和ARCH参数即可：
比如在Mac 下编译 Windows 64位可执行程序，用：
CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build main.go
在Mac系统执行完上面的命令就会编译生成软件包在Windows系统上的可执行文件（.exe文件）
如果是Windows 下编译 Mac 64位可执行程序，用：
SET CGO_ENABLED=0
SET GOOS=darwin
SET GOARCH=amd64
go build main.go
事实上，除了用于.go的Go源码文件，构建标签和文件名后缀这些条件编译规则可以作用于任何go tool可以编译的源码文件，包括.c和.s文件。Go标准库中，尤其是runtime，syscall，os，net包中包含了大量这种例子。咱们一定要去看看，多学习，尤其是身边有像小张这样又壕又凶的队友的同学们，一定把今天我说的这些都学会……。
