Go语言技术文章
-
围绕 Go sync.Pool 升级后命中率、对象身份和延迟变化，建立可重复的小实验，区分 API 契约、垃圾回收和业务所有权问题，并给出是否继续池化的判断清单。420 收藏 -
Go net/http.Transport 返回 error 时，先区分 HTTP 响应与传输失败，再沿错误链识别取消、超时、连接和 URL 原因，并据此安排日志与重试。419 收藏 -
Go sync.Pool 不是固定容量的对象缓存，Get 可能忽略池、池中对象也可能被自动清理。本文从 New、Get、Put 和 GC 的真实生命周期出发，排查配置看似没有生效的原因，并给出可观测、可安全归还的复用写法。485 收藏 -
sync.Pool归还对象不等于立即释放内存，也不会自动关闭外部资源。文章解释容量保留、外部引用和所有权错误，给出按容量筛选缓冲区的示例及对象池适用判断。247 收藏 -
围绕 Go sync.Pool 结果不稳定的常见现象，解释 Get 的任意取值、对象自动移除、初始化清理、所有权边界和业务状态选型，给出可复用的缓冲区排查思路。331 收藏 -
sync.Pool 的 Get 方法本身没有 error 返回值。遇到‘返回错误’时，应先区分 nil、类型断言失败和复用对象残留状态，再回到 Put 前的重置与调用方逻辑排查。486 收藏 -
Go 升级后 context.Cause 返回值变化，先不要把它当成标准库回归。应按构造函数、首次取消时机、父子 Context 和错误身份四层排查，区分 ctx.Err 的取消状态与 Cause 的具体原因。135 收藏 -
Go HTTP2Config.StrictMaxConcurrentRequests决定HTTP/2流额度满时等待还是增加连接。文章对比两种策略，给出客户端配置示例，并区分流额度、连接预算与业务并发限制。267 收藏 -
context.Cause只读取取消原因，不会关闭资源或等待协程退出。文章区分取消信号、阻塞点、资源所有权和结束确认，并用文件导出示例说明如何安排cancel、Close与返回结果。187 收藏 -
Go context.Cause 看起来不稳定，通常不是 Cause 随机变化，而是父子 context 的第一次取消顺序、CancelCauseFunc 调用时机或超时 API 选择不明确。本文用最小代码拆开 Err、Cause、取消顺序和并发入口，给出可复查的排查方式。118 收藏 -
context.Cause 返回的 error 不能只靠字符串判断。本文从取消信号的生命周期出发，说明如何用 ctx.Err() 判断标准状态，用 errors.Is 和 errors.As 判断自定义原因，并区分主动取消、超时和父级传播。238 收藏 -
Go 升级后 runtime.KeepAlive 相关代码出现差异时，先不要把问题归因于 API 随机变化。本文从对象可达性、终结器、底层资源句柄、数据竞争和 unsafe/cgo 约束五条线定位原因，并给出正确放置 KeepAlive 的最小写法。396 收藏 -
使用 bytes.Buffer 时，Grow(n) 不是越大越好。本文按固定大小、近似大小和未知大小三种输入场景，说明如何估算 n，区分 len 与 cap，并给出避免频繁扩容和过度预分配的实用流程。372 收藏 -
runtime.KeepAlive 只保证对象在指定位置前仍然可达，不负责关闭文件描述符、连接或其他外部资源。本文从终结器提前运行的风险出发，说明 KeepAlive 的正确位置、显式 Close 的责任和资源持续占用的排查方法。176 收藏 -
Go runtime.KeepAlive 只负责在指定调用点保持对象可达，不会修复数据竞争或非法指针。本文按资源句柄、终结器、unsafe/cgo 与并发边界拆解结果不稳定的排查方法。423 收藏