哪些大型 Go 项目正在使用 Echo 框架？想学习一下它们的项目结构。

[joesonw]

go 的工程结构看这个就好了: https://github.com/golang-standards/project-layout

[rv54ntjwfm3ug8]

@joesonw #1 这个结构好像不太适合 Web 项目

[Glauben]

@theklf4 正好这两周都在研究 kratos 的项目结构，来吧，kratos-layout 整起。https://github.com/go-kratos/kratos-layout

[lesismal]

@joesonw
又是一个受害者，早期被别人带跑偏了。。。

先看下 go 作者主力和一众人怎么喷这个项目早点纠正下姿势吧:joy:：
https://github.com/golang-standards/project-layout/issues/117

[joesonw]

@lesismal rcox 自己本来就爱喷，很多人喷的是这个名字误导人。这个只是从多个知名项目提取的一个总结结构，很具参考价值。就算是官方的也肯定不是一味的采取，参考后根据自己的需求调整才是最好。

[lesismal]

@joesonw 这个项目的工程结构真的没什么可参考的。

[RedisMasterNode]

@lesismal 然而实际工程里面这个项目结构挺好用，不管 rcox 喷还是不喷，适合的就是好的。实践里面我们很多工程都按这个目录来，也清晰明了没出现什么问题。

所以也不存在什么受害人，要我说盲目跟风 rcox 的才是受害人

[FrankAdler]

@joesonw #1 真不建议参考这个结构，槽点太多了
比如 cmd ，代指多个 main 入口，正常情况下这种颗粒太粗了，真正多个入口，更建议独立一个项目出来
比如 pkg ，代指可被引入的包，正常情况下可被引入的包，更建议也独立一个仓库，放在某一个项目的子目录下并不合适
比如 internal ，代指内部使用，更建议作为一个业务功能的子目录，作为数据定义等，内部使用，而不是直接暴露出来但是又不让引入，而且也不建议引入业务项目的子目录作为，参考上一条
其他没有业务代码的懒得说了，但是整体上来说，这个目录结构有点分层不清醒
老实说，简单的 mvc 加个 service 都比这样强

[leoleoasd]

我们的项目：github.com/eduoj/backend ，3 万行代码，应该不算小项目

[leoleoasd]

当然也算不上大

[lesismal]

@RedisMasterNode
第一，这与跟风完全无关，我不是因为 rsc 开贴而跟风，我自己的工程结构都是自己设计。
既然说到跟风，你有没有思考过哪种人擅长跟风？自己的设计能力不足、缺少判断力的人，才经常跟风，工程结构这种事情涉及到一定的设计审美能力，但还不至于是难度很大的事情、也不至于太过影响工程效率，因为即使工程结构不漂亮、只要团队人员都熟悉后形成项目规范、那项目就能足够有效推进了。各种语言，项目结构多了去了，对于工程效率，通常是约定大于配置
你觉得这个好，大概率是因为你在自己的 go 项目积累初期阶段没有自己花心思去认真思考和设计工程结构，刚好又看到有可以参考的就直接拿来用、并且用习惯了，用习惯之后其实就无所谓了。所谓的实践里你们很多工程按这个目录来也清晰明了没出什么问题，但你有没有想过其实如果你早期是参考了一个其他模板，习惯后也照样清晰没什么问题？因为这中工程结构，只是目录结构而已，并不是那些决定项目生死的算法、数据结构、框架基础设施实现质量最主要因素，比如高并发高性能，一些算法、数据结构、系统编程能力直接决定了项目能否满足性能要求（尤其是对单点性能要求很高、不是无状态那种随便加硬件就能解决的类型）。所以你说这个模板你们很多项目用着没什么问题——这说法没毛病，确实没什么问题，但这并不能证明它真的就是好，并不是所有人都能够像你们一样能够轻易接受别人的某种设计审美，而且至少我接触的高阶开发人员里，不喜欢这个模板的人居多

第二，先不论这个模板好不好，作者自己冠以 standard 。项目种类很多，你要是类似 spring 或者 larval 或者什么框架之类的，自带工程结构作为自己框架的 standard 那无话可说，然而你不是框架、只是个目录结构，跟中文那些文档类的 star 项目没什么本质区别。并且冠以 go 语言本身的 standard ，作者要脸吗？说句不好听的，这叫鸠占鹊巢、沽名钓誉，个人觉得这不仅不严谨，而且不道德

第三，说说这个模板到底好不好。不同的项目类型有不同的模块、组件需要，对应不同的目录结构通常是项目自家人员设计更贴合实际审美，通常大家倒是有一个共识——对于很多不同场景时没有银弹，既然没有银弹，即使是再去研究并且列举它哪里不好都是对时间的浪费。所以这个作者搞一个自以为通用适合所有项目类型的模板（只是目录结构），我觉得说他是招摇撞骗也不为过

[superfatboy]

我也来学习一下子！

[kongkongyzt]

@FrankAdler 同感, 这个项目的结构其实并不是万能的, 而且槽点也挺多, 你说的那几个槽点我也感同身受. 大家项目各自的规模大小, 实际情况并不相同, 只能说这个项目提供了一种参考, 而且多是命名上的参考, 没有必要全盘接受.

rsc 没出这个回应前, 之前的项目组里面要求即使项目没有 web, 也没有脚本, 只是一个简单的命令行二进制工具, 也没有依赖任何外部包, 源码里面也要带上 web, scripts, vendor, deployments 等目录, 问了就说这是 Go 官方的 standard, 有一种类似宗教里面那种原教旨狂热. 自从出了这个回应后, 技术总监被打脸了, 再也没有继续坚持.

[BeijingBaby]

适合自己的就是最好的，也许某一种你认为“不好的”，比如关于 /pkg 的争论，当大家都这么做的时候，其实就是一种标准了。

[BeijingBaby]

来自 rsc 的回复。

There are two problems with this GitHub repo:

it claims to host Go standards and does not, in the sense that these are in no way official standards
the project-layout standard it puts forth is far too complex and not a standard
Regarding "why not tell us the standard Go project layout and we'll update the doc?", that only addresses point 2. If there really were standards, they would be in the main Go project doc tree. The standard for project layout would also be a lot shorter. I appreciate your trying to provide a useful resource, but calling it 'golang-standards' is claiming more than it is.

But for the record, the minimal standard layout for an importable Go repo is really:

Put a LICENSE file in your root
Put a go.mod file in your root
Put Go code in your repo, in the root or organized into a directory tree as you see fit
That's it. That's the "standard".

In particular:

It is not required to put commands in cmd/.
It is not required to put packages in pkg/.
It is not required to put web stuff in web/.
It is not required to put APIs in api/.
It is not required to put web stuff in web/.
It is not required to put configurations in configs/.
It is not required to put systemd scripts in init/.
It is not required to put shell scripts in scripts/.
It is not required to put Docker files in build/package/.
It is not required to put CI configs in build/ci/.
It is not required to put deployment configs in deployments/.
It is not required to put test support in test/.
It is not required to put documentation in docs/.
It is not required to put supporting tools in tools/.
It is not required to put examples in examples/.
It is not required to put third_party code in third_party/.
It is not required to put git hooks in githooks/
It is not required to put static assets in assets/.
It is not required to put website data in website/.

The importable golang.org/x repos break every one of these "rules".

[josefacoder]

你们说了这么多,能不能回答一下问题呀