slice是否可以去掉在某些情况下的copy动作

[Owen-Zhang]

在学习源码的过程中,有一个疑惑：
bfe_net/textproto/reader.go 文件中
func (r *Reader) ReadLineBytes() ([]byte, error) {
line, err := r.readLineSlice()
if line != nil {
buf := make([]byte, len(line))
copy(buf, line)
line = buf
}
return line, err
}
为何要重新copy源数据呢，像这种ReadLineBytes方法一般都使用在单goroutine中，有一种情况下会出现问题:就是取了一部分数据后，在没有使用数据的情况下，又去取数据，有概率的会改变掉上次取出还未使用的数据，但这种情况是少数，在使用时可以自行处理，大都数情况下都不需要copy到新的slice中，减少gc压力

这是个人的看法，可能有地方没分析到，麻烦你们指点一下

[xuleiming]

1. ReadLineBytes 为何要拷贝一次？
   ReadLineBytes 以及相关的 ReadLine readLineSlice 这几个函数都来自golang标准库 net/textproto。在移植到 bfe_net/textproto 时保持了原样，未作改动。
   在标准库中，也有人提了同样的问题，
   net/textproto: seemingly unnecssary buffer copy and reassignment in Reader.ReadLineBytes golang/go#28436
   可参考此链接中的回答。

2. bfe中是否可以使用不拷贝的版本？

2.1 bfe中调用相关函数的情况
事实上在 bfe 中没有调用过 ReadLineBytes()，而是调用了另外两个相关函数：
在 readRequest 时，读取首行调用了 ReadLine();
读取后续的header部分调用了 readContinuedLineSlice() 方法。

2.2 ReadLine()
func (r *Reader) ReadLine() (string, error) {
line, err := r.readLineSlice()
return string(line), err
}
ReadLine() 中有一次 slice --> string 的类型转换，这个类型转换会有一次内存拷贝，这是golang string类型的特性造成的，无法避免。
bfe 使用了返回 string 的 ReadLine() 而不是返回 slice 的 readLineSlice()，应该是出于使用string处理起来比较方便的考虑，此处性能被放在了第二位。
因为只有request的首行用到了此函数，所以性能影响并不大。

2.3 readContinuedLineSlice()
该函数是较低级的函数，不存在 issue 中说的内存拷贝问题。

2.4 结论
bfe 中只在一个goroutine中处理请求，原则上不做内存拷贝不会带来问题；使用了内存拷贝的方法是出于处理string方便的考虑。因为只复制了请求的首行，性能影响并不大。
bfe 此处的行为和 golang 标准库是一致的，可以继续参考 golang 标准库的做法。