最近在用 Go 做一个小型的 gateway 服务。PHP 请求 Go 的 tcp server，然后 Go 根据命令参数开启多个 goroutine 去调度 php-fpm 执行不同的脚本并组合结果返回。 想来只是利用 goroutine 的便利并发执行逻辑，如此简单直接。
不过在测试的时候 PHP 发送 socket 的 json 数据发生了明确的截断，后来发现是我煞笔的被 bufio.Reader 坑了，真是无言以对。
问题重现
因为是长连接，PHP 每次发一段 json ，都会加上换行符\n分割。我就很理所当然的用起了*bufio.Reader.ReadLine()。就像下面的代码：
func handleConn(conn net.Conn) {
reader := bufio.NewReader(conn)
for {
// 读取一行数据，交给后台处理
line,_,err := reader.ReadLine()
if len(line) > 0{
fmt.Printf("ReadData|%d \n",len(line))
executeBytes(line)
}
if err != nil{
break
}
}
conn.Close()
}
可是当 PHPer 测试发送大json数据的时候，发现了明确的截断：
ReadData|4096|{"ename.com":........,"yunduo.com":{"check":[1
// 又一次
ReadData|4096|{"ename.com":........,"yunduo.com":{"getWhois"
想让 json 还没读完就被截断。我记得默认的 bufio.Reader 的大小是 4096，所以 bufio.Reader 的行为是读满了buffer就return出来啊。。我勒个去。我总不能写个很大的size吧。
reader := bufio.NewReaderSize(conn,409600)
PHP 发送的测试数据最大可能得到100k左右，平均只有<10k。我服务端每次都开一个100k+的bufio.Reader太浪费啦。最后变成，开小了截断，开大了浪费，我煞笔了。
解决方式
既然bufio.Reader.ReadLine() 玩不下去了，我就只能回到最原生的用法，例如改造后的代码：
func handleConn(conn net.Conn) {
buf := make([]byte, 4096)
var jsonBuf bytes.Buffer
for {
n, err := conn.Read(buf)
if n > 0 {
if buf[n-1] == 10 { // 10就是\n的ASCII
jsonBuf.Write(buf[:n-1]) // 去掉最后的换行符
executeBytes(jsonBuf.Bytes())
jsonBuf.Reset() // 重置后用于下一次解析
} else {
jsonBuf.Write(buf[:n])
}
}
if err != nil {
break
}
}
conn.Close()
}
这样就是每次读出4096的字节，读到\n就截断，和之前放入buffer的数据取出来一起交给后续运算。这样不用在意传来的数据大小，只要\n分隔符正确就没有问题。
经过测试也没有发现什么业务问题，pprof也没有看出明显的性能瓶颈。那就这么用着，我松一口气交差。
又煞笔啦
bufio.Reader.ReadLine()应该没有那么傻吧。如果buffer满了就return，我怎么知道只是满了还是读到\n的返回，万一内容刚好buffer长度呢！下班回家翻源码，我又煞笔了：
// ReadLine is a low-level line-reading primitive. Most callers should use
// ReadBytes('\n') or ReadString('\n') instead or use a Scanner.
//
// ReadLine tries to return a single line, not including the end-of-line bytes.
// If the line was too long for the buffer then isPrefix is set and the
// beginning of the line is returned. The rest of the line will be returned
// from future calls. isPrefix will be false when returning the last fragment
// of the line. The returned buffer is only valid until the next call to
// ReadLine. ReadLine either returns a non-nil line or it returns an error,
// never both.
//
// ......
func (b *Reader) ReadLine() (line []byte, isPrefix bool, err error) {
line, err = b.ReadSlice('\n')
if err == ErrBufferFull {
// Handle the case where "\r\n" straddles the buffer.
if len(line) > 0 && line[len(line)-1] == '\r' {
// Put the '\r' back on buf and drop it from line.
// Let the next call to ReadLine check for "\r\n".
if b.r == 0 {
// should be unreachable
panic("bufio: tried to rewind past start of buffer")
}
b.r--
line = line[:len(line)-1]
}
return line, true, nil
}
......
}
我擦。如果读出的满了buffer，当不是\n结尾，isPrefix是true。我从来没注意过中间这个返回值的意思。真是被自己坑了。其实代码可以这么写：
func handleConn(conn net.Conn) {
reader := bufio.NewReader(conn)
var jsonBuf bytes.Buffer
for {
// 读取一行数据，交给后台处理
line,isPrefix,err := reader.ReadLine()
if len(line) > 0{
jsonBuf.Write(line)
if !isPrefix{
executeBytes(jsonBuf.Bytes())
jsonBuf.Reset()
}
}
if err != nil{
break
}
}
conn.Close()
}
RTFD
结论：Read The Fucking Documentation
有疑问加站长微信联系（非本文作者）
