ʕ◔ϖ◔ʔ
ʕ◔ϖ◔ʔ
```go engine := gin.Default() // COPY http://host:port/path engine.Match([]string{"COPY"}, "/path", func(c *gin.Context) { c.String(http.StatusOK, "Hello") }) ```
```go query.Use(db) // use UnderlyingDB() query.Q.User.WithContext(ctx).UnderlyingDB().Clauses(clause.OnConflict{ Columns: []clause.Column{{Name: "id"}}, DoUpdates: clause.Assignments(map[string]interface{}{"count": gorm.Expr("GREATEST(count, VALUES(count))")}), }).Create(&users) ```
me too.
当前我就是用上面的方式控制 session 操作的超时时间，这个 timeout 算是基于经验设置的超时时间。 举个极端的例子，比如：timeout 设置的是一分钟，此时数据库查询的很慢需要很久。 当前端请求或许刷新页面、或许主动断开连接、或许网络中断。按道理当前端一旦断开，session 查询可以立即终止。 但是 session 的 ctx 和 http 的 ctx 没有建立关联，session 操作依然在进行，要等到自定义 ctx cancel，或者是数据库结果返回，或者是其他异常原因。 虽然自定义超时时间不影响系统运行，但是如果传入一个 http ctx 能够更优雅的串联起 session 逻辑，也能留给开发者更多的选择。 这个功能会改变 Session 接口的签名，会影响...
这个写法有点难理解
和 `runtime.KeepAlive()` 用途类似吗？
标题 “技术” 写成了 “技木”
不错，如果里面的示例代码不用图片，而是美化后可复制的文字代码就更棒了
鸟大可否解说一下最近关于**增强 ServeMux 路由**的讨论： https://github.com/golang/go/issues/61410 https://github.com/golang/go/discussions/60227
我个人对此情况有以下理解： 覆水难收不能算是 `io.Reader` 的锅，应该是所有流式 IO 都是有状态有偏移量的，如过不记录偏移量，那下面这个代码永远跳不出 for 循环： ```go func readAll(r io.Reader) { buf := make([]byte, 1024) for { r.Read(buf) } } ``` 如果可以重复读，那么从网络中已经读了 1000G 想回溯到第一个字节重新读，这 1000G 总得有个地方存。尽管一些语言可能提供了可重复读取的功能，那也只是对 IO 的封装工具类，并且重读能力有限，多数要按需定制，对已读数据的缓存大小需要考量。