指针、内存、defer 与资源安全

Go 自动管理内存，但文件、响应体、计时器和 goroutine 仍有明确生命周期。指针不是“更快”的通行证，逃逸到堆也不等于错误。正确目标是先保证所有权清楚，再通过编译器诊断和基准测试优化真实热点。

一、学习目标

理解指针、地址可取性与 nil 指针
正确解释栈、堆和逃逸分析输出
使用 defer 管理文件与响应体
处理 Close 错误和循环中的资源范围
设置有限的 panic/recover 边界

二、指针语义

指针保存变量地址，& 取地址，* 解引用。Go 不支持普通指针算术：

func rename(t *Task, title string) error {
    if t == nil {
        return ErrInvalidTask
    }
    return t.Rename(title)
}

使用指针通常为了修改共享值、避免复制较大结构或表达可选性。小型只读值用指针可能增加别名和 nil 状态。是否传指针不决定对象位于栈还是堆，具体分配由编译器逃逸分析决定。

三、逃逸与测量

查看逃逸决策：

go build -gcflags=all=-m=2 ./cmd/studytasks

输出是编译器诊断，不是逐条必须消灭的警告。返回局部变量指针是安全的，编译器会安排其生命周期。接口装箱、闭包捕获和不透明调用可能导致逃逸，但优化版本会变化。

先用 go test -bench=. -benchmem 找到分配热点，再尝试值传递、预分配或减少接口转换。为了让值“留在栈上”而复制巨大结构，可能比堆分配更慢。

四、defer 的求值与顺序

defer 在当前函数返回前按后进先出执行，其参数在注册时求值：

f, err := os.Open(path)
if err != nil {
    return err
}
defer f.Close()

读取文件时通常可在返回时忽略 Close 错误；写入文件时 Close 可能报告缓冲或文件系统错误，应合并到返回结果。defer 作用于函数而不是循环迭代，在长循环中每次打开资源，应提取一个小函数，让每次迭代及时关闭。

五、资源所有权

创建资源的层通常负责关闭，除非 API 明确转移所有权。HTTP 客户端收到成功响应后必须关闭 Body，并在可能复用连接时读完有限响应。计时器、ticker 与取消函数也属于资源：

ctx, cancel := context.WithTimeout(parent, 2*time.Second)
defer cancel()

cancel 释放计时器并通知子操作，不应只等超时自然发生。返回一个 io.ReadCloser 意味着调用方获得关闭责任，文档和测试必须表达这一点。

六、panic 与 recover

recover 只在正在展开同一 goroutine 的 defer 中有效：

func runCommand() (err error) {
    defer func() {
        if value := recover(); value != nil {
            err = fmt.Errorf("internal panic: %v", value)
        }
    }()
    return execute()
}

入口边界可以把 panic 转成诊断和非零退出码，但不能保证被破坏的共享状态仍可继续使用。不要 recover 后返回 nil。库函数应优先返回错误；只有调用方式本身违反不可恢复契约时才考虑 panic。

七、从知识点到工程契约

本篇的示例最终要进入可维护的 Go 包，而不是停留在 main 中的一次性片段。先把目标写成调用者可以观察的契约：输入是否允许零值或 nil，返回值是否是快照，错误能否通过 errors.Is/As 分类，函数是否启动 goroutine、取得资源或修改共享状态。然后再选择结构体、接口、函数值或泛型；抽象形式必须服务于契约，而不是反过来决定需求。

可以用以下顺序把知识点落到工程代码：

在独立小函数中写出最小成功路径，并让 go test 能直接调用。
加入一个与“认为指针参数一定更快或一定在堆上”相关的失败样例，确认失败可观察且不会留下半完成状态。
把文件、网络、时间、环境或并发等外部因素改成显式依赖，测试使用临时目录、固定时钟或本地服务。
运行 gofmt、vet 和相关测试；涉及共享状态时追加 -race，涉及解析器时追加有上限的 fuzz。
最后再评估 API 是否需要导出。只在同一模块内部使用的能力保留在 internal，避免过早形成公共兼容负担。

审查代码时至少回答四个问题：谁拥有数据，谁允许修改，失败由谁处理，工作由谁停止。Go 的垃圾回收只解决不可达内存回收，不会替你关闭文件、取消请求、等待 goroutine 或恢复被覆盖的数据。只要其中一个问题没有答案，就先缩小函数或包的边界。

本篇最重要的能力是“理解指针、地址可取性与 nil 指针”。不要用注释替代可执行约束：能由类型表达的就交给类型，能由构造或验证表达的就返回错误，能由测试观察的就保存回归用例。示例扩展到 StudyTasks 时，还要保持领域包不导入命令行、文件和 HTTP 细节。

八、验证策略与复盘

验证分为静态、动态和故障三层。静态层检查格式、模块图和分析器；动态层用正常输入证明结果；故障层主动制造取消、权限、损坏数据、超时或竞态。一次测试通过只能说明执行过的路径符合断言，不能证明所有输入都安全，因此需要让每条关键契约至少对应一个成功用例和一个反例。

建议保存下面的复盘记录：

项目	需要记录的证据
版本	`go version`、模块与 toolchain 指令
输入	最小正常值、零值、边界值和非法值
状态	调用前后数据、资源和 goroutine 的所有者
输出	返回值、错误链、stdout/stderr 与日志字段
失败	第一个失败点、清理动作和可恢复状态
工具	实际运行的 test、race、vet、benchmark 或 build 命令

完成验证后，用另一份干净临时目录重跑，不读取开发机的用户配置、缓存数据或真实网络。若测试只能按特定顺序成功，就说明状态隔离仍不完整。若为了让测试通过必须长时间 sleep，应改用 channel、WaitGroup、context 或可注入时钟表达确定的同步条件。

本篇可以用以下目标做验收：正确解释栈、堆和逃逸分析输出；使用 defer 管理文件与响应体；处理 Close 错误和循环中的资源范围。把它们逐项转成命令输出或断言，而不是写成“人工看起来正确”。当实现与预期不符时，先保存最小失败样例，再调整设计。

发布前再做一次反向审查：从调用方而不是实现内部出发，写出一个完全不知道具体类型和文件布局的使用示例；从故障点出发，假设进程在每个 I/O 之后被取消；从升级出发，假设下一版改变字段或默认值。若调用方必须知道未公开细节、故障会留下无法判断的状态，或升级只能覆盖旧数据，契约就还不完整。把这三个场景加入测试或文档，比继续增加抽象更有价值。

最后检查示例能否被复制到一份最小程序独立运行，所有导入、错误处理和清理是否完整。教学代码可以省略与主题无关的界面，却不能省略会改变正确性的 context、Close、边界检查或同步。对为了篇幅省略的部分要明确标注，不能让读者把伪代码误当成生产承诺。

九、StudyTasks 实践

为 JSON 仓储实现读取和写入资源管理，确保每个打开文件都有明确关闭责任。添加一个写入失败测试和一个故意 panic 的命令边界测试；用逃逸分析与基准记录优化前后的分配，而不是凭感觉改指针。

完成本节后，不要只保存代码或 SQL。请同时保存执行命令、关键输出和失败案例；学习笔记真正有价值的部分，是能够说明输入、状态变化、输出以及失败后的恢复方式。

十、常见错误

认为指针参数一定更快或一定在堆上
在循环中 defer 大量关闭，直到整个外层函数结束才释放
写文件时永远忽略 Close 返回的错误
忘记调用 context 的 cancel 函数
recover 后返回成功，隐藏状态可能已损坏

十一、练习与自测

比较返回大结构值与指针的基准和逃逸输出。
把循环中打开文件的代码提取到小函数，验证文件及时关闭。
实现组合主错误与 Close 错误的辅助函数。
写测试证明 recover 无法捕获另一个 goroutine 的 panic。

自测时应在干净的临时目录或临时数据库中重新执行，而不是依赖上一节遗留的状态。如果结果与预期不同，先记录实际输出，再缩小问题范围。

十二、官方资料

版本行为与二手文章不一致时，以本系列固定版本的官方文档、命令输出和可重复测试结果为准。

上一篇：结构体、方法、接口与组合下一篇：函数值、闭包、泛型与约束