问题描述
我正在用golang开发一个客户端/服务器应用程序，客户端和服务器上都存在某些逻辑实体(列表有限)
I'm developing a client/server application in golang, and there are certain logical entities that exist both on client and server(the list is limited)
我想确保此实体的某些代码仅包含在服务器部分中，而不包含在客户端中(反之亦然很好，但不那么重要).
I would like to ensure certain code for this entities is included ONLY in the server part but NOT in the client(wise versa is nice, but not so important).
天真的想法是依靠死代码消除，但根据我的简短研究，这不是处理任务的可靠方法...... go build 根本不会从事实上它可能是通过反射使用的(没有人关心它不是，也没有选项可以调整它)
The naive thought would be to rely on dead code elimination, but from my brief research it's not a reliable way to handle the task... go build simply won't eliminate dead code from the fact that it may have been used via reflection(nobody cares that it wasn't and there is no option to tune this)
更可靠的方法似乎是将代码拆分到不同的包中并适当地导入，这似乎可靠但使代码过于复杂，迫使您在不同的包之间物理拆分某些实体并始终牢记这一点...
More solid approach seems to be splitting code in different packages and import appropriately, this seems reliable but over-complicates the code forcing you to physically split certain entities between different packages and constantly keep this in mind...
最后还有构建标签，允许在同一个包下有多个文件为客户端和服务器有条件地构建
And finally there are build tags allowing to have multiple files under the same package built conditionally for client and server
使用构建标签的动机是我希望在不引入任何合成实体的情况下保持代码尽可能干净
The motivation with using build tags is that I want to keep code as clean as possible without introducing any synthetic entities
用例:有一定的加密例程，客户端使用公钥，服务器使用私人...代码逻辑上属于同一实体
Use case: there are certain cryptography routines, client works with public key, server operates with private... Code logically belongs to the same entity
您会选择什么选项?为什么?
What option would you choose and why?
推荐答案
这个死代码消除"已经——部分——由 go 工具完成.go 工具不包含导入包中的所有内容，只包含需要的内容(或者更准确地说:它排除了可以证明无法访问的内容).
This "dead code elimination" is already done–partly–by the go tool. The go tool does not include everything from imported packages, only what is needed (or more precisely: it excludes things that it can prove unreachable).
例如这个应用程序
package main; import _ "fmt"; func main() {}
与以下相比，生成的可执行二进制文件小了近 300KB(在 Windows amd64 上):
results in almost 300KB smaller executable binary (on windows amd64) compared to the following:
package main; import "fmt"; func main() {fmt.Println()}
可排除的东西包括函数、类型甚至未导出和导出的变量.这是可能的，因为即使使用反射，您也不能仅通过将名称作为 string 值来调用函数或实例化"类型或引用包变量.所以也许你不应该担心那么多.
Excludable things include functions, types and even unexported and exported variables. This is possible because even with reflection you can't call a function or "instantiate" types or refer to package variables just by having their names as a string value. So maybe you shouldn't worry about it that much.
随着 Go 1.7 的发布，它变得更好:阅读博客文章:较小的 Go 1.7 二进制文件
With Go 1.7 released, it is even better: read blog post: Smaller Go 1.7 binaries
因此，如果您很好地设计了类型和函数，并且没有在枚举函数和类型的地方创建巨大的"注册表(这会显式地生成对它们的引用，从而使它们不可排他)，则编译后的二进制文件将只包含实际从导入的包中使用.
So if you design your types and functions well, and you don't create "giant" registries where you enumerate functions and types (which explicitly generates references to them and thus renders them unexcludable), compiled binaries will only contain what is actually used from imported packages.
我不建议对此类问题使用构建标记.通过使用它们，您将有额外的责任自己维护包/文件依赖项，否则由 go 工具完成.
I would not suggest to use build tags for this kind of problem. By using them, you'll have an extra responsibility to maintain package / file dependencies yourself which otherwise is done by the go tool.
您不应该将代码设计和分离到包中，以使您的输出可执行文件更小.你应该根据逻辑设计和分离代码到包中.
You should not design and separate code into packages to make your output executables smaller. You should design and separate code into packages based on logic.
我会在真正需要时将东西分成包，并适当地导入.因为这确实是您想要的:一些代码仅用于客户端，一些仅用于服务器.在设计和编码阶段，您可能需要多考虑一点，但至少您会看到结果(实际属于/被编译到客户端和服务器中的内容).
I would go with separating stuffs into packages when it is really needed, and import appropriately. Because this is really what you want: some code intended only for the client, some only for the server. You may have to think a little more during your design and coding phase, but at least you will see the result (what actually belongs / gets compiled into the client and into the server).
这篇关于拆分客户端/服务器代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，WP2