Go语言包内未使用的常量、函数、结构体方法会被打包进可执行二进制吗

Go 工具链默认编译流程（go build 无特殊编译参数）会在链接阶段执行全链路死码消除（DCE）：仅保留从 main 包入口出发存在直接/间接引用路径的代码、数据到最终二进制，无引用路径的成员会被完全移除。
这是所有场景判定的基础。

分场景的未使用成员剔除规则 #

• 场景1：仅定义大量SQL常量的Const包
  未被main引用的SQL字符串常量，不会被纳入最终二进制。
  很多人误以为只要import了包，包里的字符串常量全都会被打进二进制，这是和C语言“全局常量编译期写入只读段”的逻辑搞混了。Go的字符串常量是延迟生成的：只要某个常量没有被任何可达代码引用，对应的字符串字面量根本不会被写入二进制的只读数据段，哪怕整个Const包被main直接导入也一样。

• 场景2：定义大量返回SQL字符串函数的Func包
  未被main调用的函数、以及函数内部携带的SQL字符串字面量，不会被纳入最终二进制。
  Go的包级函数死码消除粒度为单函数级：只要函数没有从main入口可达的调用路径，整个函数的机器码、函数内引用的所有字符串字面量都会被链接器直接丢弃。
  注意常见踩坑点：如果图方便在init函数里把所有SQL函数塞到一个全局map里供运行时动态查找，那这些函数就算没被main直接调用，也会因为init的可达性被全部保留，这是最常见的导致未使用代码被打进二进制的原因。

• 场景3：混合定义SQL常量+返回常量函数的mix包
  两部分未引用成员都会被连带剔除：没有被任何可达代码引用的包级常量，会被直接移除；没有被调用的返回函数，连同它所引用的对应常量，会被一并清理。
  比如main仅调用InsertA()的场景下，InsertB()、UpdateA()函数，以及它们关联的insertB、updateA常量，都会因为没有可达引用路径被完全删除，不会留下孤立的字符串数据占用二进制空间。

• 场景4：按表定义结构体和关联方法、常量的Struct包
  未被引用的结构体、结构体方法、仅被这些方法引用的SQL常量，不会被纳入最终二进制。
  死码消除粒度为类型级：只要某个结构体类型没有被任何可达代码实例化、作为字段/参数类型引用，那么这个类型的所有方法、所有只被这些方法访问的私有常量，都会被链接器移除。比如main仅使用A结构体的场景下，B结构体、B的所有方法、仅被B方法引用的insertB等SQL常量，都会被完全剔除。
  例外情况：如果结构体实现了某接口并在init函数中注册到全局接口注册表（比如数据库驱动的自动注册逻辑），那么即使main没有直接引用这个结构体，也会因为注册逻辑的可达性被保留。

重构方案选型结论 #

针对250+张表的SQL聚合需求，两种结构的二进制体积控制效果没有本质差异——不管是把每张表拆成独立包，还是单包下用空结构体按表归类SQL，Go的死码消除都会精准剔除未被业务引用的部分，不会因为包的拆分粒度产生额外的体积膨胀。
具体选型建议：

• 优先选择「单包多文件、按表定义专属空结构体挂载SQL和方法」的结构：
  • 无跨包导入开销，不用反复调整导出/非导出的访问权限，开发者跳转定位代码的路径最短
  • 不会产生冗长的包导入路径，新开发者按表名找文件的成本更低
  • 体积控制效果和拆独立包完全一致：某张表的SQL、方法只要没被业务代码用到，就会被完全从二进制里删除，不会产生无意义的体积增长
• 仅当需要对特定表的SQL做硬隔离（比如禁止普通业务代码直接调用高危的批量删除逻辑，仅对外暴露受限接口）时，才需要为对应表拆分独立包。硬拆250个独立包除了让import路径变得冗长，没有任何实际收益。

之前旧代码中分散在各个hugeX、hugeY包中的重复SQL，全部聚合到这个单包中按表归类即可，完全不需要担心未使用的表SQL会导致二进制变大。

内容的提问来源于stack exchange，提问作者Kokizzu