定义golang结构的成本：函数调用时

**定义 Go 结构的成本** 在 Go 中，函数调用时定义自己的请求和响应类型是一种常见的做法。这种方法提供了记录函数主体中结构的优势，尤其是在处理具有不同类型请求和响应的多个函数时。然而，对于在函数调用中定义类型与在包作用域中定义类型之间的成本，存在担忧。

我偶然发现了一个定义自己的请求和响应类型的函数。

func doSomething() {

    type request struct {
        resourceID string
    }

    type response struct {
        resourceContents *Data
    }

    request := initializeRequest()
    result := dispatchRequest(request)

    ...
}

我认为这具有在函数主体中记录请求和响应的结构的巨大优势。当许多此类函数位于同一个文件中并且它们的请求和响应结构都有不同的类型时，这种便利性尤其明显：在函数外部定义类型意味着我必须以不同的方式命名它们。

不过，我担心这样做的成本： 让函数调用声明自己的类型与在包作用域中声明该类型相比，成本更高吗？

此外，这种方法是否惯用？

解决方案

类型是一个编译时概念，它们的范围（通常）不会影响运行时速度，因为编译器在这些情况下生成的代码不会注意到原始类型（请阅读更多内容 Type erasure and reification），而反射是异常值，但你在这里没有反映。

也就是说，我发现这段代码有点可疑：

request := initializeRequest()

initializerequest 在哪里定义的？它必须知道 request 类型，所以我假设它也是函数的内部？否则代码将无法编译。这些考虑因素在许多情况下限制了函数本地结构的实用性，但如果您确实拥有本地的所有内容，我认为尽可能隐藏类型是一个很好的做法。

在更大规模的项目中，测试问题也会发挥作用。如果类型和函数隐藏在作用域中，您如何测试对其起作用的类型和函数？

到这里，我们也就讲完了《定义golang结构的成本：函数调用时》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！