Thiece

@Nazz
在你的 github 这个代码中，BufferReset2 虽然用了 unsafe 但是操作的都是 Buffer 结构体内定义的字段，没有越界访问或对未初始化内存的操作，所以现在没有安全上的问题。
BufferReset2 中，更改了 buf 、off 和 lastRead 字段，在 BufferReset1 中仅更改了 off 字段。可能是更多字段引起额外的内存分配导致的。

@Nazz
Go 语言中的结构体是将 Field 按照声明的顺序进行内存布局。
如果没有使用 unsafe.Offsetof 之类的方法，unsafe.Pointer 获取到的地址就是该结构体的首地址。
结构体的首地址就是其第一个字段的地址，等同于访问该结构体的第一个字段。

BufferReset2 不仅重置了 buf 和 off ，还重置了 lastRead 。

```
package main

import (
"fmt"
"unsafe"
)

type MyData struct {
length int
data int
}

func main() {
data := MyData{
length: 5,
data: 100,
}

fmt.Println("Before:", data)

// 获取 MyData 结构体的地址，并转换为通用指针
ptr := unsafe.Pointer(&data)

// 模拟不加偏移量的修改操作
*(*int)(ptr) = 200

fmt.Println("After:", data)
}
```

如果你错误地修改了结构体的私有字段，可能会导致数据状态的不一致。例如，可能会影响缓冲区（ buffer ）的长度和容量，使其不匹配。

bytes.Buffer 的实现在未来版本中发生变化也会出现问题。

@shunia
你说得对，恶劣这个词现在来看确实用的不妥，但我不明白这和应润尽润之间有什么逻辑关联；
另外关于你认为的有价值的回复，这一点我持保留意见，也不是面向产品与开发者的。

这个帖子的回复楼层，十分贴切的展示的国内开源环境的恶劣。
开源项目，代码和订阅地址都开源了，对代码不放心可以自己 Code review ，对编译不放心可以自己编译；
觉得订阅源不好可以自己部署一个订阅源。

flush 操作会给 ES 集群带来压力，尤其是在高并发的情况下。
可以引入一个缓存层（如 Redis ），缓存部分高频查询的结果。

有没有一种可能，这些问题可以直接在 V2EX 上面聊

@xiaocaiji111
你是懂多进程的