测试所有函数在数据量在 1000 的情况下的表现。
$ go test -run=none -bench=1000$ -benchmem
测试结果：
goos: darwin
goarch: amd64
pkg: github.com/poloxue/gotin
BenchmarkIn_1000-8 30000 45074 ns/op 8032 B/op 1001 allocs/op
BenchmarkInIntSlice_1000-8 5000000 313 ns/op 0 B/op 0 allocs/op
BenchmarkInIntSliceSortedFunc_1000-8 30000000 44.0 ns/op 0 B/op 0 allocs/op
BenchmarkSortInIntSlice_1000-8 20000 65401 ns/op 32 B/op 1 allocs/op
BenchmarkInIntSliceMapKeyFunc_1000-8 100000000 17.6 ns/op 0 B/op 0 allocs/op
BenchmarkMapKeyInIntSlice_1000-8 20000 82761 ns/op 47798 B/op 65 allocs/op
PASS
ok github.com/poloxue/gotin 11.312s
表现前三依然是 InIntSlice、InIntSliceSortedFunc 和 InIntSliceMapKeyFunc，但这次顺序发生了变化，MapKeyFunc 表现最好，17.6 ns/op，与数据量 10 的时候相比基本无变化。再次验证了前文的说法。
同样的，数据量 1000000 的时候。
$ go test -run=none -bench=1000000$ -benchmem
测试结果如下：
goos: darwin
goarch: amd64
pkg: github.com/poloxue/gotin
BenchmarkIn_1000000-8 30 46099678 ns/op 8000098 B/op 1000001 allocs/op
BenchmarkInIntSlice_1000000-8 3000 424623 ns/op 0 B/op 0 allocs/op
BenchmarkInIntSliceSortedFunc_1000000-8 20000000 72.8 ns/op 0 B/op 0 allocs/op
BenchmarkSortInIntSlice_1000000-8 10 138873420 ns/op 32 B/op 1 allocs/op
BenchmarkInIntSliceMapKeyFunc_1000000-8 100000000 16.5 ns/op 0 B/op 0 allocs/op
BenchmarkMapKeyInIntSlice_1000000-8 10 156215889 ns/op 49824225 B/op 38313 allocs/op
PASS
ok github.com/poloxue/gotin 15.178s
MapKeyFunc 依然表现最好，每次操作用时 17.2 ns，Sort 次之，而 InIntSlice 呈现线性增加的趋势。一般情况下，如果不是对性能要特殊要求，数据量特别大的场景，针对单类型的遍历已经有非常好的性能了。
从测试结果可以看出，反射实现的通用 In 函数每次执行需要进行大量的内存分配，方便的同时，也是以牺牲性能为代价的。
总结
本文通过一个问题引出主题，为什么 Go 中没有类似 Python 的 In 方法。我认为，一方面是实现非常简单，没有必要。除此以外，另一方面，在不同场景下，我们还需要根据实际情况分析用哪种方式实现，而不是一种固定的方式。
接着，我们介绍了 In 实现的三种方式，并分析了各自的优劣。通过性能分析测试，我们能得出大致的结论，什么方式适合什么场景，但总体还是不能说足够细致，有兴趣的朋友可以继续研究下。
