Go问答技术文章
-
Go net/http.Transport 升级后出现连接复用、延迟或连接数变化时，不要先猜版本回归。本文用最小客户端、httptrace、Response.Body 生命周期和显式 Transport 配置，建立一套可比较的定位方法。349 收藏 -
Go http.Client 遇到 307/308 重定向时，请求方法和请求体只有在 GetBody 可用时才能安全重放。本文说明 NewRequest 的常见 Reader 边界、自定义 Reader 的补救方式与 CheckRedirect 的控制方法。388 收藏 -
Go net/http.Transport结果不稳定时，先区分传输错误、HTTP状态与正文变化。文章说明连接复用和响应体处理误区，给出有界GET诊断示例，并用httptrace记录复用线索。163 收藏 -
围绕 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 收藏