直接二进制查看 go 编译的二进制文件，会发现带有 import 包信息，挺敏感的
dep github.com/cespare/xxhash/v2 v2.3.0 h1:UL815xU9SqsFlibzuggzjXhog7bL6oX9BbNZnL2UFvs=
dep github.com/google/uuid v1.6.0 h1:NIvaJDMOsjHA8n1jAhLSgzrAzy1Hgr+hNrb57e+94F0=
dep google.golang.org/grpc v1.70.0 h1:pWFv03aZoHzlRKHWicjsZytKAiYCtNS0dHbXnIdq7jQ=
dep google.golang.org/protobuf v1.36.2 h1:R8FeyR1/eLmkutZOM5CWghmo5itiG9z0ktFlTVLuTmU=
dep github.com/golang-jwt/jwt/v5 v5.2.1 h1:OuVbFODueb089Lh128TAcimifWaLhJwVflnrgM17wHk=

但查了下没发现去除的办法

github.com/golang/go/issues/50501 直接关了？

翻 go 编译器源码，找到关于这块信息的部分去除，diy 一个编译器就行了。

github.com/burrowers/garble garble 可以去掉但是可能有副作用

同好奇，c 语言也有同样问题

不用开源的 自己撸就完了

有个邪教方法 把三方包下载到本地自己改成随机名字 import 如何

这也算敏感信息？安全过度了吧。按这种标准大部分语言的编译打包工具全不用玩了，自己发明一种？

＃4 用了 10 年 c 语言，我也好奇你说的这个，c 语言哪里有 build info ？

如果是在字符串区就直接删了呗，应该不影响功能，注意对齐就行

＃7 「自主研发」的含金量

8＃ 符号表吧可能...

遥遥领先

SBOM 清单，在安全与合规审计，软件溯源时还是很有用的，建议留着。
要说怎么去除，我也不知道

你可以自己把库都 fork 下来改个包名 import

主要是上面的意思是不想让某部门知道是用 Go 写的

buildinfo 留着是利大于弊，藏着掖着弄的好像有什么见不得人的地方一样（公开依赖项不利于宣称自主研发吗？ ）。

即便把 buildinfo 去掉，只需要简单的命令 strings ./xxx 就可以看到内部的依赖软件路径。

加个壳行不？

strip --remove-section=.go.buildinfo ./bin
可以删一些 section ，但想让人看不出来是 go 写的基本没可能

直接用 upx 压缩,再剔除二进制文件的 upx 的字段,这样至少静态分析没法判断是 go 写的

我也是这个思路，是在 cmd/go/internal/load.setBuildInfo