最近遇到一个问题，因为业务需求，需要对接第三方平台.
而三方平台提供的一些HTTP(S)接口都有统一的密钥生成规则要求.
为此我们封装了一个独立的包 xxx-go-sdk 以便维护和对接使用.
其中核心的部分是自定义HTTP Client,如下:
一些平台会要求appKey/appSecret等信息，所以Client结构体就变成了这样，这时参数还比较少, 而且是必填的参数，我们可以提供构造函数来明确指定。
看起来很满足，但是当我们需要增加一个 Timeout 参数来控制超时呢?
或许你会说这还不简单，像下面一样再加一个参数呗
那再加些其他的参数呢？那构造函数的参数是不是又长又串，而且每个参数不一定是必须的，有些参数我们又会考虑默认值的问题。
为此，勤劳但尚未致富的 gophers 们使用了总结一种实践模式
首先提取所有需要的参数到一个独立的结构体 Options，当然你也可以用 Configs 啥的.
然后为每个参数提供设置函数
这样我们就为每个参数设置了独立的设置函数。返回值 func(*Options) 看着有点不友好，我们提取下定义为单个 Option 调整一下代码
当我们需要添加更多的参数时，只需要在 Options 添加新的参数并添加新参数的设置函数即可。
比如现在要添加新的参数 Timeout
这样后续不管新增多少参数，只需要新增配置项并添加独立的设置函数即可轻松扩展，并且不会影响原有函数的参数顺序和个数位置等。
至此，每个选项是区分开来了，那么怎么作用到我们的 Client 结构体上呢?
首先，配置选项都被提取到了 Options 结构体重，所以我们需要调整一下 Client 结构体的参数
其次，每一个选项函数返回 Option,那么任意多个就是 ...Option，我们调整一下构造函数 NewClient 的参数形式，改为可变参数，不再局限于固定顺序的几个参数。
然后循环遍历每个选项函数，来生成Client结构体的完整配置选项。
那么怎么调用呢？对于调用方而已，直接在调用构造函数NewClient()的参数内添加自己需要的设置函数(WithXXX)即可
当需要设置超时参数，直接添加 WithTimeout即可,比如设置3秒的超时
配置选项的位置可以任意设置，不需要受常规的固定参数顺序约束。
可以看到，这种实践模式主要作用于配置选项，利用函数支持的特性来实现的，为此得名 Functional Options Pattern，优美的中国话叫做「函数选项模式」。
最后, 我们总结回顾一下在Go语言中函数选项模式的优缺点
所谓Go语言式的接口，就是不用显示声明类型T实现了接口I，只要类型T的公开方法完全满足接口I的要求，就可以把类型T的对象用在需要接口I的地方。这种做法的学名叫做Structural Typing，有人也把它看作是一种静态的Duck Typing。除了Go的接口以外，类似的东西也有比如Scala里的Traits等等。有人觉得这个特性很好，但我个人并不喜欢这种做法，所以在这里谈谈它的缺点。当然这跟动态语言静态语言的讨论类似，不能简单粗暴的下一个“好”或“不好”的结论。我的观点:
Go的隐式接口Duck Typing确实不是新技术, 但是在主流静态编程语言中支持Duck Typing应该是很少的(不清楚目前是否只有Go语言支持).
静态类型和动态类型虽然没有绝对的好和不好, 但是每个都是有自己的优势的, 没有哪一个可以包办一切. 而Go是试图结合静态类型和动态类型(interface)各自的优势.
那么就从头谈起：什么是接口。其实通俗的讲，接口就是一个协议，规定了一组成员，例如.NET里的ICollection接口：
public interface ICollection {
int Count { get}
object SyncRoot { get}
bool IsSynchronized { get}
void CopyTo(Array array, int index)
}
这就是一个协议的全部了吗？事实并非如此，其实接口还规定了每个行为的“特征”。打个比方，这个接口的Count除了需要返回集合内元素的数目以外，还隐含了它需要在O(1)时间内返回这个要求。这样一个使用了ICollection接口的方法才能放心地使用Count属性来获取集合大小，才能在知道这些特征的情况下选用正确的算法来编写程序，而不用担心带来性能问题，这才能实现所谓的“面向接口编程”。当然这种“特征”并不但指“性能”上的，例如Count还包含了例如“不修改集合内容”这种看似十分自然的隐藏要求，这都是ICollection协议的一部分。
