Go中大量使用匿名函数配合defer是否合理？此类用法是否普遍？

你的这种写法完全没问题，而且是很多Go开发者都会采用的最佳实践之一，刚好对应你想实现的两个核心目标：

1. 缩短互斥锁持有时间 #

用匿名函数把加锁、defer解锁和需要同步的代码包裹起来，是控制锁作用域的标准操作。毕竟锁的持有时间越长，并发竞争的概率就越高，程序的性能瓶颈就越明显。

如果不用匿名函数，把锁放在函数开头，那么整个函数执行过程（包括中间的HTTP请求、复杂逻辑）都会持有锁，这会严重降低并发效率。而用匿名函数限定锁的作用域，只在真正需要同步的代码段持有锁，这是非常合理的优化手段——很多生产代码里都能看到这种写法，甚至有人会把这个模式封装成复用函数：

func withLock(s *Something, fn func()) {
    s.Lock()
    defer s.Unlock()
    fn()
}

// 调用时更简洁
withLock(s, func() {
    // 仅这里持有锁
})

但即使直接写匿名函数，也是完全可以接受的，可读性足够强。

2. 确保HTTP响应体及时关闭 #

HTTP客户端的连接池依赖响应体的关闭来复用TCP连接，如果漏写resp.Body.Close()，确实会导致连接无法复用，不断创建新连接，浪费系统资源。

你提到的手动在每个错误分支写Close()不仅繁琐，还容易漏写（比如后续加了新的错误分支却忘了加Close）。而用匿名函数包裹HTTP请求逻辑，配合defer自动关闭响应体，就能保证无论分支如何跳转，响应体都会被关闭——这也是Go社区处理这类资源清理问题的常规操作。

当然，你也可以把HTTP请求的逻辑封装成单独的函数（比如fetchAPI），但如果只是函数内部的一段局部逻辑，用匿名函数包裹会更紧凑，不需要额外定义函数。

总结 #

这种“用匿名函数限定defer作用域”的写法，完全符合Go语言“用defer保证资源清理”的设计思路，是社区广泛认可的做法，很多有经验的Go开发者都会这么写，你不用有顾虑。

内容的提问来源于stack exchange，提问作者win-t