面向对象是将连接生命周期、资源约束、释放行为建模为可验证对象实体，通过状态管理（如acquiredcount/isclosed）、责任封装（closeable接口）、对象图追踪（pprof+埋点）和契约化验证（strictmode/故障注入）实现句柄泄漏的精准防控。
面向对象不是用来“模拟”句柄锁死的，而是把连接生命周期、资源约束、释放行为建模成可验证的对象实体，让评估从模糊猜测变成实例级断言。关键不是写类，而是用对象关系表达“谁该关、何时关、关没关”。
把连接抽象成带状态的实体
长连接不能只看作 socket fd，它应是一个有明确生命周期、归属上下文、释放契约的对象。例如：
- 每个上传任务（Task）持有一个 ConnectionManager 实例
- ConnectionManager 内部维护 acquiredCount、releasedCount、lastUsedAt、isClosed 标志
- 每次调用 getConn() 生成唯一 connID，并记录调用栈（用于定位泄漏源头）
- close() 被调用时，不仅执行底层 syscall.Close()，还校验 isClosed == false && acquiredCount > releasedCount
这样，一句 if task.connMgr.leaked() 就能返回布尔结果，而不是靠日志里翻“close missing”。
用对象边界隔离资源责任
句柄锁死常因责任错位：网络层以为业务层会关，业务层以为连接池自动回收。面向对象通过封装强制划清边界：
- TrackerClient 和 StorageClient 必须各自实现 Closeable 接口，且 Close() 方法不可为空
- 分块上传 BlockUploader 不直接持有 socket，只依赖注入的 ConnectionProvider，后者承诺：每次 provide() 后必须对应一次 release()
- 在构造函数中传入 context.WithTimeout，让连接对象自带超时感知能力，超时自动触发 onTimeoutClose()
这就避免了“某处忘了 defer resp.Body.Close()”这类散点问题——它被收编进对象契约里。
用对象图还原泄漏路径
当 fd 持续上涨时，不要只跑 lsof -p，而要导出运行时对象图：
- Go 程序可通过 runtime/pprof 调用
pprof.Lookup("goroutines").WriteTo(w, 1)获取活跃 goroutine 堆栈 - 结合自埋点：每个 Connection 对象创建时打点
conn_created{type="storage", id="c_8a3f"}，关闭时打conn_closed{id="c_8a3f"} - Prometheus 查询：
count by (id) (conn_created) - count by (id) (conn_closed) > 0，直接列出未关闭的 connID - 再用该 ID 反查 goroutine 堆栈，精准定位到哪一行代码申请了连接却没走释放路径
用对象约束驱动修复验证
改完代码不能只等压测后看 fd 是否下降，要用对象行为做闭环验证：
- 修改后启动时，强制启用
ConnectionManager.strictMode = true，它会在每次 acquire 时检查前一个 conn 是否已 close - 单元测试里 mock ConnectionProvider，断言
provider.ReleaseAll()被调用且无残留 - 在 CI 阶段注入 fault injection：随机让某次 close() 失败，验证对象是否抛出 ErrConnNotReleased 异常而非静默吞掉
不复杂但容易忽略。
