Nlife2021-10-22老师，这句话"一个 Go 项目里的 internal 目录下的 Go 包，只可以被本项目内部的包导入。项目外部是无法导入这个 internal 目录下面的包的。" 能否再讲解具体一些呢？比如后续我们的课程中是否会讲到这块的实践操作？作者回复: 举个例子，假设我们有两个go module，两个module的结构如下： . ├── module1 │ ├── go.mod │ ├── internal │ │ └── pkga │ ├── pkg1 │ └── pkg2 └── module2 ├── go.mod └── pkg1 module1中的internal/pkga包可以被module1的pkg1和pkg2包所导入。 但无法被module2的pkg1包所导入。
共 5 条评论59
Geek_c1467d2021-10-22另外goalng标准布局可以参考下这个：https://github.com/golang-standards/project-layout作者回复: 这个已经被Go官方否了，https://github.com/golang-standards/project-layout/issues/117#issuecomment-828503689。
共 3 条评论26
Bynow2021-10-23这部分东西讲解的循序渐进，太棒了，是很多晚上噶好难过没有涉及到的，讲解的可以看出来这这水平和积累，这门课太值了。爱了作者回复: 感谢支持。你的收获对我来说就是最大的鼓励。
共 2 条评论18
Linuaa2021-10-23老师可以讲讲 ”Reproducible Build“ 吗，看了一些文章感觉抓不到重点。谢谢老师~作者回复: 可重现构建，顾名思义，就是针对同一份go module的源码进行构建，不同人，在不同机器(同一架构，比如都是x86-64)，相同os上，在不同时间点都能得到相同的二进制文件。
17
郭纯2021-10-22对于最小的布局 我觉的只要这几个文件就好了 main.go. go.mod go.sum. 既然是小项目代码量不多所有代码在 main.go 文件就好。作者回复: Go语言技术负责人Russ Cox曾谈过这个问题，他认为一个项目的最小布局至少有一个go.mod，一个LICENSE（针对开源项目）。然后就像你说的，在项目根目录下放置go代码即可。对于tiny项目，一个main.go也是可以的。
16
光明2022-02-05这一节虽然没有搞懂太多，反复看了3遍，后发现这一章节，是现行很多 GO 语言书籍中缺少部分。非常感谢Tony 老师的这么细致有详细的讲解。细微之处见真功夫。作者回复: 👍
13
alexgreenbar2022-04-21这些难道不是一门语言一开始就应该解决的问题吗？10多年过去了，go居然还在纠结这个，在这点上，感觉go的创建者们故意忽视了软件工业过去20年的积累，不比较语言本身，只考虑构建：java有maven，rust有cargo，并且它们都有集中可访问的repository用于分享，go到现在都没有这个机制，也是服了。作者回复: 我觉得你提到的是两件事： 1. go项目标准布局的事儿 到目前为止，Go官方并没有给出书面标准。文中内容也是基于Go项目自身以及Go社区的主流实践整理而得的。 Go语言技术负责人Russ Cox曾谈过这个问题，但他仅给出对于go项目最小布局的观点，他认为一个项目的最小布局至少有一个go.mod，一个LIC ENSE（针对开源项目）。其他都有程序员自行确定。不可否认，没有基本标准布局，这的确给规模稍大一些的项目的开发人员带来困惑。 2. 没有统一的集中的module/包库 Go没有，且也是故意这么设计的。你提到Go团队故意忽视了软件工业过去20年的积累，但从Go团队角度来看，这是他们的一种解决安全风险的方案。可以看看这篇文章：https://tonybai.com/2022/04/02/how-go-mitigates-supply-chain-attacks 从今年来npm暴露出的一系列安全问题来看，集中库的确也存在各种各样的问题。
8
Long_hz2021-10-22老师你好，请问一下loccount 工具编译的时候缺少go.mod需要怎么解决？作者回复: loccount只是一个代码统计工具，你可以用其他类似的工具替代。如果非要编译loccount工具，并且它没有go.mod的话，可以下载loccount工具源码后，在你的本地为其创建一个go.mod，然后编译试试。
共 2 条评论7
lesserror2021-10-22Tony Bail 老师的这一讲关于Go项目的布局标准的讲解非常专业。极客时间孔令飞老师的专栏，对这一布局方式很很好的实践。 有以下疑问，烦请老师抽空解答一下： 1. “ 这些依赖包是缓存在 vendor 目录下的”。那我可以是否可以理解为，接是把这些包的源码文件下载到本地的vendor目录中呢？ 2. “库项目仅通过 go.mod 文件明确表述出该项目依赖的 module 或包以及版本要求就可以了。” 请问一下，go.mod文件中还能表述依赖的 module吗？ 我看go.mod文件中的内容一般不都是依赖的第三方包和版本吗？ 3. 使用vendor的优势是什么？对比使用 go module形式，只是访问第三方包的源码路径的不同吗？ 4. 老师，后面的项目代码会在这一讲的目录基础上来构建吗？这一讲没有实际的代码操作，如果没有实际的操作感受，很容易遗忘这些概念。作者回复: 感谢认真的思考和棒棒的问题，我也认真回答一下:) 1. 是的，如果采用vendor模式，依赖包会缓存在vendor目录下。 2. 在go module机制进入go之前，也就是gopath构建模式时代，我们谈到的所有依赖都是包与包的版本；但go module引入后，所有的版本信息都绑定在module上，所以你在go.mod中看到的require块中的依赖都是module与module的版本，不再是包。 3. 06和07讲会提到。 4. 06,07讲会有例子。
共 2 条评论6
qinsi2021-10-22诶，ESR也写go了？作者回复: 是的。loccount就是它的作品。他还用go编写了将gcc代码从svn仓库无损(提交历史)地迁移到git的工具。可以看看他切换到go的感悟：https://gitlab.com/esr/reposurgeon/blob/master/GoNotes.adoc
6