When OpenAI API calls start timing out in production, the real problem is usually not “OpenAI is down.” The real problem is you don’t know which hop is failing: DNS, TLS handshake, proxy path, or your own connection pool. ...
线上调用 OpenAI API 一旦出现超时，最烦的不是“偶发失败”，而是你不知道到底卡在 DNS、TLS、代理，还是你自己的连接池。 这篇给你一套可直接落地的排查顺序：先判定超时发生在哪一段，再用指标和最小实验定位，最后给可复制的 Go 配置模板，避免同类事故反复出现。 ...
很多团队已经把 LLM 接进业务，但一到“多步任务 + 调工具 + 失败重试”就开始失控：日志看不懂、状态回不去、成本还飙升。 这篇给你一个能直接落地到 Go 服务里的最小可用方案：工具调用闭环、会话记忆分层、错误恢复可回放。 ...
Most teams can connect an LLM in a demo. The real pain starts in production: multi-step tasks, flaky tool calls, unclear retries, and rising cost. This guide gives you a pragmatic Go-first blueprint for shipping an Agent workflow that can survive real incidents. ...
记录笔记或者写博客的时候经常会直接复制mac截图插入图片，默认复制得到的是无损png图片，图片体积比较大，占空间带宽，就基于go实现了个命令行批量压缩工具。 ...
问题提出 提出这个问题主要是因为日常开发中有这样的场景，比如服务配置热加载或者一些全局缓存的异步更新，通常会单独启一个协程去获取最新数据再通过赋值更新原数据。因为更新逻辑是单独的协程，变量的写和读就存在并发访问的情况，于是就有了这个问题。一个简单异步刷新例子 如下： ...
最近使用xorm更新db的时候碰到一个挺有意思的问题，db中字段类型是日期datetime，对应go model中的字段是time.Time类型，在分别使用model和map两种方式进行更新时，使用model的方式更新能得到正确结果，db中的日期能被更新成当地时间；使用map kv的方式进行更新时db中的字段被更新成了格林尼治标准时间。都是取的go time.Now为什么更新结果不一样呢？ // demo type TimeTest struct { ID int64 `xorm:"not null pk autoincr INT(11) 'id'"` UpdateTime time.Time `xorm:"update_time"` } func UpdateTime(o *xorm.Session) { o.Table(new(TimeTest)).Where("id = ?", 1).Update(&TimeTest{ UpdateTime: time.Now(), }) o.Table(new(TimeTest)).Where("id = ?", 1).Update(map[string]interface{}{ "update_time": time.Now(), }) } ...
分布式限流器也是项目开发中常用的，基于redis incr指令可以比较方便快捷的实现一个分布式限流器，因为这个指令自身的原子性，所以不用开发者考虑计数过程的并发问题。下面是go代码实现。 ...
最近经常用go写一些脚本，为了执行效率，一般会开启多个goroutine并发执行,脚本中通常会调用一些线上服务或者数据库读写数据，为了不影响线上服务运行,为了不影响线上服务运行就要对执行的goroutine数量进行限制，避免并发太大打垮线上服务。下面就简单写一个goroutine并发控制器。 ...
生成二进制可执行文件 首先，写一个go main函数，这里就简单输出以下hello world。 package main import "fmt" func main() { fmt.Println("hello word") } 执行go build -gcflags "-N -l" -ldflags=-compressdwarf=false -o main main.go生成可执行二进制文件。 开启gdb调试 执行gdb main开始gdb调试。通过i files查看程序入口地址，再这个地址打上断点。 ...