@evercyan 感谢，这个规则我明白，Parse(text string) (*Template, error) 反响适配 Must 感觉很奇怪，我感觉 #15 的 Must 写法也不影响 Must 链式调用。

我的疑惑就是：如果 Parse 不返回 *Template ，也不影响 Must 的链式调用。

func Must(t *Template, s string) *Template {
if err := t.Parse(s); err != nil {
panic(err)
}
return t
}

type Template struct{}

func (t *Template) Parse(s string) error {
return nil
}

@evercyan 看到了，通过 Must 调用确实可以做到链式调用。但是这么设计总感觉是本末倒置呀。

@maocat 你确定是因为为了链式调用，Parse 返回了 (*Template, error) 两个参数，还怎么做链式调用？

前 3L 不知道想表达什么，我个人觉得这么定义 func (t *Template) Parse(text string) error 确实可行，但不清除设计这个接口时为何要返回 *Template

可能是通过 ja3 指纹

@mizuki9 可以参考 https://stackoverflow.com/questions/24714665/why-is-rune-in-golang-an-alias-for-int32-and-not-uint32

@mizuki9 这个问题 Google 一搜一大堆，大致有几点：1. Unicode 编码是从 U+0000 到 U+10FFFF ，即使是有符号的 int32 也可以表示。

当时还试用了一下，看到 UI 直接没有继续使用的欲望了，OP 在做这个选题的时候可能都没有简单的市场调研和竟品分析。
1. UI 确实不咋好看。
2. 部署需要轻便，简单的 html 引入 js css 就可以部署运行，弄个 docker 有点重了。
3. 参考下列竟品，做好交互。
https://petstore.swagger.io/
https://elements-demo.stoplight.io/
https://scalar.com/
https://redocly.github.io/redoc/

@guo4224 #12 正解

我大概理解了你的想法：就好比分卷压缩，只要得到第一个压缩包（第一个压缩包内含有元数据），跳过任意个块包，也照样可以解压后面的任何一块压缩包。

这应该实现不了吧，块与块之间大概率是存在依赖关系的，环环相扣，一环缺失就会导致后面数据无效。不太了解 zlib 的二进制格式，OP 要想深入研究可自行查阅资料。
比如：ts (MPEG2-TS) 这种分块格式是经过设计的，每一块内都含有元数据，不依赖前后 ts 数据块，每一块都单独可用。

还有：压缩包只是个容器，里面的数据才是有用的，一段数据被分块压缩后，怎么知道想要的数据被压缩分块到了哪个块区？这也是一个问题。

如果是 HTTP 客户端可以改造的更简单一些，例如：

func Get(u string) (*http.Response, error) {
resp, err := http.Get(u)
if err != nil {
return nil, err
}

encoding := resp.Header.Get("Content-Encoding")
if encoding == "deflate" { // 代表 body 使用了 zlib 压缩
body := resp.Body
rc, exx := zlib.NewReader(body)
if exx != nil {
_ = body.Close()
return nil, exx
}
resp.Body = rc
}

return resp, nil
}

和 zlib 无关，只是流式解析没处理好而已。

package main

import (
"bytes"
"compress/zlib"
"fmt"
"io"
"os"
"sync"
)

//goland:noinspection GoUnhandledErrorResult
func main() {
bin1, _ := os.Open("1.bin")
defer bin1.Close()
bin2, _ := os.Open("2.bin")
defer bin2.Close()

input := new(bytes.Buffer)
input.ReadFrom(bin1)
zr, err := zlib.NewReader(input)
if err != nil {
fmt.Printf("zlib error: %v\n", err)
return
}

wg := new(sync.WaitGroup)
wg.Add(1)
go func() {
defer wg.Done()
io.Copy(os.Stderr, zr)
zr.Close()
fmt.Printf("\noutput over\n")
}()

input.ReadFrom(bin2)

wg.Wait()
fmt.Printf("main over\n")
}

输出结果：
{"t":null,"s":null,"op":10,"d":{"heartbeat_interval":41250,"_trace":["[\"gateway-prd-us-east1-c-0bwh\",{\"micros\":0.0}]"]}}{"t":null,"s":null,"op":11,"d":null}
output over
main over

是这样吗？

input := new(bytes.Buffer)
output, _ := zlib.NewReader(input)
// 压缩的数据流往 input 里面写入。
// 从 output 读取解压后的数据流。

@Immunize #28 真的假的？有相关的测试文档没

你们上来就争论，却不跑一遍作者的示例代码。
Linux Ubuntu i5-8500 测试结果是：

go1.21.6 下确实如那篇文章所说 g 明显比 f 快。
go1.22rc2 下 g 和 f 效率几乎无差异。

问下 jooq 需要根据表结构生成代码，在那一块儿？怎么生成的？

掌握流量密码，撕比确实能招来一大堆回复。