—- 采用ANSI标准形式时，参数个数可变的函数的原型声明是：
type funcname(type para1, type para2, …)
—- 这种形式至少需要一个普通的形式参数，后面的省略号不表示省略，而是函数原型的一部分。type是函数返回值和形式参数的类型。
—- 采用与UNIX System V兼容的声明方式时，参数个数可变的函数原型是：
type funcname(va_alist)
va_dcl
—- 这种形式不需要提供任何普通的形式参数。
type是函数返回值的类型。va_dcl是对函数原型声明中参数va_alist的详细声明，实际是一个宏定义，对不同的硬件平台采用不同的类型来定义，但在最后都包括了一个分号。因此va_dcl后不再需要加上分号了。va_dcl在代码中必须原样给出。va_alist在VC中可以原样给出，也可以略去。
此外，采用头文件stdarg.h编写的程序是符合ANSI标准的，可以在各种操作系统和硬件上运行；而采用头文件varargs.h的方式仅仅是为了与以前的程序兼容。所以建议使用前者。
很遗憾，Go中没有这样的设计，当然，目前大多数相对高级的语言都取消了宏定义的方法，虽然这样降低了程序员对程序的掌控能力，但是这样更容易保证程序运行的一致性。俗话说，有舍也有得吧。对于想要实现Release版本与Develop版本体现不一样的运行效果，可以通过定义特殊的标记常量或者变量来实现，这一点在Java等很多语言上都是一样的。
golang中没有类似C语言中条件编译的写法，比如在C代码中可以使用如下语法做一些条件编译，结合宏定义来使用可以实现诸如按需编译release和debug版本代码的需求
build tags 是通过代码注释的形式实现的，要写在文件的最顶端；
go build指令在编译项目的时候会检查每一个文件的build tags，用来决定是编译还是跳过该文件
build tags遵循以下规则
示例：
约束此文件只能在支持kqueue的BSD系统上编译
一个文件可能包含多行条件编译注释，比如：
约束该文件在linux/386 或 darwin/386平台编译
需要注意的点
正确的写法如下：
编译方法:
具有_$GOOS.go后缀的go文件在编译的时候会根据当前平台来判断是否将该文件导入并编译；同样适用于处理器架构判断 _$GOARCH.go。
两者可以结合起来使用，形式为： _$GOOS_$GOARCH.go
示例：
文件名必须提供，如果只由后缀的文件名会被编译器忽略，比如：
这两个文件会被编译器忽略，因为以下划线开头的文件都会被忽略
