@hopingtop #9 我从 OP 的描述中。理解到的就是
1. 之前 文件中是保存的 明文，现在想 文件中保存 密文
2. 想改最少的代码，实现这个功能。

得出上述建议，如果我理解错了，就当我没说 ~ ~#

按照我的理解，OP 是不是想这样？

type A struct {
conf string `json:"Config"`// 存入你存入的配置
Config string `json:"-"` // 这个先为空， 假设已 JSON 序列化做示例
}

然后你看看 A 这个结构体怎么生成的，是不是一次生成，到处用。
如果是：那你就再 生成方法那里， 类似于 执行一个 Init() 方法，把 conf -> Config


这样你在使用的地方用 A.Config 就不需要改动。

如果这个结构体生成的地方很少，那么可能几行代码就解决了。

有没有大佬，继续讨论一下 触发防火墙的规则的问题？

是因为 base64 中的某段数据假设 '3122ABC' = '我是恶意的'
防火墙规则 base64('我是恶意的') ,然后 base64(image).Match(base64(Rule)) ？
防火墙发现是 base64 的编码，就用规则 base64 之后再去匹配？

@matrix1010 #20 其实网上有比较多的案例，只是大部分情况下，遇不到。大多数场景，我们所产生的数据包 浮动是有限的，所以里面的 buffer 大小就算扩容也有限，本身来说 sync.Pool 是会回收，只是比较慢，通常来说一般要经过 2-3 个 GC 标记确认不用了才回收，但是这里一般流量较大，才会使用到 sync.Pool 的场景，所以可能导致一直回收不了。

第二点就是 我们是容器部署，容器层限制了 2G 的内存使用量。 但是这个容器限制对于 Go 语言是感知不到的。在 go >1.19 版本,才出现有一个参数配置好像是 GOMEMLIMIT=xx ，告知 Go 我限制了内存。这个时候感到分配压力，GC 才会频繁活动！

但是我们恰巧是 <1.19 , 我们物理机本身是 32G 内存，所以 Go 感觉内存是杠杠够的，但是 Docker 的 Limit ，导致在 Docker 层直接把进程 Kill 了 https://i.imgur.com/huX6coX.png

@hopingtop #17 '我确定是' -> '我不确定是'

@Nazz #16 我确定是我表示不清楚，还是太久了，你忘记了，所以我们说的不是同一个东西，你可以再去看看代码
```go
// NewEncoder returns a new encoder that writes to w.
func NewEncoder(w io.Writer) *Encoder {
return &Encoder{w: w, escapeHTML: true}
}

// Encode writes the JSON encoding of v to the stream,
// followed by a newline character.
//
// See the documentation for Marshal for details about the
// conversion of Go values to JSON.
func (enc *Encoder) Encode(v any) error {
if enc.err != nil {
return enc.err
}

e := newEncodeState()
defer encodeStatePool.Put(e)
```
```go
var encodeStatePool sync.Pool

func newEncodeState() *encodeState {
if v := encodeStatePool.Get(); v != nil {
e := v.(*encodeState)
e.Reset()
if len(e.ptrSeen) > 0 {
panic("ptrEncoder.encode should have emptied ptrSeen via defers")
}
e.ptrLevel = 0
return e
}
return &encodeState{ptrSeen: make(map[any]struct{})}
}
```
核心消耗内存的地方是 encodeState

@Nazz #14 唉，encode/json 底层实现用了 全局 sync.Pool ，包括 json-iterator 也是类似实现，所以包不了。 如果 json-iterator 提供设置 自定义的 pool 就好了，可惜也没有

@Trim21 #11 场景比较特殊，当前绑定了 json 序列化，后期准备改成 pb 一劳永逸

我才看了 op 的代码，如果你真的想实现 mem 的高效利用，可以参考上面的链接实现或许会更好！

目前 mempool 有点问题就是，限制了上限，但是释放不了下限，没有考虑到 release 机制， 最终还是可能会把所有 buffer 都撑大！

我们也遇到 op 一样的问题，json 序列化会撑爆内存，就是因为 sync.Pool + json.Buffer 导致的。
当 99%的数据是小包 1%的数据突然来一个几十 MB 的大包，那么有可能后面 sync.Pool 里面的 buffer 都会变成几十 MB ，就会导致内存爆掉。

这个问题，Golang 有最新的提案和实现, 就是动态优化 buffer 的大小。 但是还没有合并！

相关 code 链接 https://go-review.googlesource.com/c/go/+/471200

@ttentau1 #288 感谢，脚本很好用！！！

@hopingtop #284 我发现是，如果我回复后，不刷新，那么
当前显示，换行就是失效的！

然后刷新后，就是正常的！

@hopingtop #283 看来换行还是失败了， 难道要加 \n
加入\n 测试


换行\n

我想知道，为什么我回车换行 失效了！

是我使用问题，还是本地环境问题？

这是一个我期望换行的语句！

换行！


3 个回车换行！

先个体吧，等你做大再开公司也不迟，只要有收入了，开公司是分分钟的事情！
公司平时维护成本还是比较费精力或者费钱，没必要。 对于大多数场景，特别是一些平台的 API 权限， 个体与小微差不了什么！

非常感谢，脚本很好用！你很酷 https://i.imgur.com/IPG5yJO.png https://i.imgur.com/IPG5yJO.png

@Saturn72 有绿茵，微微出汗，达到的目的刚刚好！ 5 公里约 50 分钟。 关于出汗这个问题，就要看抉择了，有些朋友觉得出汗不能忍， 但是夏天在所难免