@iosyyy #49 “有异常并且把异常消除才是最好的办法”，虽然很多观点是自由心证自说自话，但这句真的没法苟同的。“Let it crash”也算 Go 设计哲学之一，一开始也不算认同。Bug 处理多了，血泪教训之下对 Go 某些设计还是觉得入木三分。从这点出发，Java 如果要认真处理每个异常错误的话，也得一个一个函数 throw 而且加上签名，真的比满屏 err 好不到哪。 不过 Java 语法糖多，用修饰处理异常啥的方法手段确实比较多且节省时间。其他就不多说了，语言流行自有他的道理，讨论多了也累。

要我说不如 DDD 。写到很多复杂业务的时候，无脑 controller 其实发现很多代码不知道放哪里，最后又都放到 controller 里，分了其实最后也没怎么分。DDD 从开始会让你拆分业务领域，持久层跟表现层其实都不是业务的重点。

要我说 Go 优雅，肯定是 defer 跟协程了。defer 现在不知道有啥语言支持，反正 Go 里面是真的优雅跟省心。协程就不用说了，事实证明这一套 go select channel 设计，我反正还没看见别的语言能说超过 Go 的。

@iosyyy #42 现在满屏还在说 Go 的 err 是我最不能理解的事，有异常本来就是司空见惯的事情，你不处理不代表异常就消失了，处理少了，只能说你的错误在哪个不知道的环节被吞了而已。
我现在看见 Java 代码的 try catch 就害怕，有些甚至都不是新人，遇见异常就无脑 catch ，函数签名基本看不见几个 throw 的。

内部边界看怎么定了，如果是不同团队维护，我觉得还是上一套鉴权的好。参考各大公共 API 设计，一个 appKey 跟 secret ，测试跟生产 secret 分开就差不多行了。

@ihciah Go 是直接面向 CPU 架构编译的，特定架构是肯定会包含一些关键指令集的。特殊加速指令集就不知道了，就算不能直接用加速代码一般也会有纯算法实现的替代。

Go1.18 的时候出了架构细分，可以指定架构等级

https://github.com/golang/go/wiki/MinimumRequirements#amd64
Go 1.18 introduced 4 architectural levels for AMD64. Each level differs in the set of x86 instructions that the compiler can include in the generated binaries:

GOAMD64=v1 (default): The baseline. Exclusively generates instructions that all 64-bit x86 processors can execute.
GOAMD64=v2: all v1 instructions, plus CMPXCHG16B, LAHF, SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3.
GOAMD64=v3: all v2 instructions, plus AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, OSXSAVE.
GOAMD64=v4: all v3 instructions, plus AVX512F, AVX512BW, AVX512CD, AVX512DQ, AVX512VL.

有没有一种可能，经验越丰富的程序员一般生产力越高…刚入行 1200 挺亏的，反而是熟手，cv 几个界面，改改参数可能就出来了

@lower 其实也有的 VO BO DTO PO 是业务属性的东西，跟语言没关系。我之前看 go python 之类的，简单一点的业务就是 MVC 走天下。复杂一点比如 DDD 之类的，不管什么语言 你都会看到一堆的 VO DTO PO 之类的。
其实在我看来各种概念都是把复杂业务从横向纵向多个角度拆分，拆碎，留出足够的独立编码，测试，最后再继承的空间。

https://github.com/andeya/gust 在 github 上看到有个库。。

1 、各个组件的日志看组件有没有提供 Logger 接口，有的话一般是把全局的 Logger 单独实现一个组件的 Logger 然后传进去，但是其实我们以前公司是不允许组件输出太多 Log 的。不然很容易就导致日志量暴表。
2 、据我所知大部分框架 RequestId 之类的还真是靠 context 往下传的，context 其实在 go 里面真的很有用，因为协程的生命周期都需要用 context 来控制。基本上你可以认为 context 就是用来跟协程进行绑定的东西，你不用 context 往下传，协程处理的生命周期就会断开，导致一些未知的 bug.
3 、Java 也不是什么地方都可以随便 Try catch 的，正常业务异常都需要 throw 出去，不然可能会丢失原始的错误信息，导致出现 bug 的时候无法排查。少数比如网络重试之类的异常可以直接 catch 掉 重试，go 里面 你要想省事就直接 进入协程处理业务进去的时候写一个 recover ，然后业务里面出错直接 panic 。我们以前就这么干，web 业务应用无所谓的。但是基础组件，中间件，我们不允许 panic

@KevinBlandy 我们以前是 web 框架用 gin ，事务封装成一个 gin 中间件，进入业务处理前先获取一个 db 事务对象，业务处理完成后提交就行。如果是无状态的业务同时有多个进程，中间可能要加个 redis 分布式锁，事务提交前要先检查锁是否过期，过期了就不能提交。

IOC 是面向业务的，小项目估计无所谓，大项目业务复杂程度没有一些基础框架支持都自己实现挺麻烦的。不过开源的 wire 跟 dig 已经很好用了

@vvzero 现在公有云反而 UDP 可以用，以前的小机房，默认 UDP 就是封禁的。。主要是 UDP 用来 DDOS 太方便了。。。

@WaterWestBolus docker 容器跟宿主机之间你可以认为多加了一层网关转发，容器绑定的 0.0.0.0:3306 只是绑定容器虚拟 IP 的 port ，dockerfile 上 expose 的只是容器端口。但是宿主的绑定 IP 一般是 docker run 的时候动态绑定的，可以用-p 参数指定，具体参考这个文档 https://docs.docker.com/engine/reference/run/#expose-incoming-ports

@ecloud 容器化除了本身的环境隔离之外，其实对运维来说更重要的是一套交付系统。即镜像库+docker pull/run/stop 。以前运维部署要么自己实现一套，要么就 ftp+ssh ，高级一点上 ansible 啥的。