可能是通过 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 需要根据表结构生成代码，在那一块儿？怎么生成的？

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

根据实际情况，自定义这几个方法中的任意一个即可实现： https://github.com/golang/go/blob/master/src/crypto/tls/common.go#L569-L601

不要啥都往 context.Context 里面塞，塞一次 ctx 就多包裹一层。

1. 可以自定义 iris 自带的 logger 。

func main() {
app := iris.New()
logger := app.Logger()
logger.Printer.Output = os.Stderr

app.Get("/hello", func(ctx *irisctx.Context) {
log := ctx.Application().Logger()
log.Info("HELLO")
})
}

2. 使用依赖注入

type DemoAPI struct {
log *zap.Logger
}

func (a DemoAPI) Hello(ctx *irisctx.Context) {
a.log.Info("HELLO")
}

至于为什么这样设计，看看这个 issue 有没有你想要的答案 https://github.com/golang/go/issues/11862

应该是 Go 文件通配设计就是如此，可以参考： https://pkg.go.dev/path/filepath#Match

不过在 Java 中确实会有 ** 这种通配写法