rate

@yeqown 看了一下，感觉跟 go-proto-validators 差不多，主要是生成规则，当然跟我这个差别也不大，proto-validaor 就是把检查错误并返回的部分也自动生成了。

@wencan 现在 proto-validator 的做法不就类似与中间件吗？ 不然如果用一个统一的中间件让服务使用， 那就需要 proto 在生成 go struct 的时候生成很多 tag 去描述参数验证的信息。

不太理解为什么会有人要死磕某一门语言， 这算是信仰吗？ 对于绝大部分人来说，编程只是一门手艺而已，随着自己的职业生涯很多时候是要有所改变或拓展的， 把自己限制死不太理解有什么意义。

@wencan 没太理解你的意思， 现在不就是在 proto 里面加 tag ，然后自动生成代码校验吗？ 你指的是哪种？

@liuhan907 是这个道理， 不过用到了 proto 就希望把 dto 的定义跟 dto 的参数验证放到一起，这样观感上更好一点。

人类在进化中充分认识到了主备高可用的重要性

你怕是不知道 Java 有多卷，你这样直接转的怕是工作都难找。 建议可以先在公司内拓展，先走全栈路线，等后端技能稳定了再 all in 后端。

加我 WX: eHk5ODE0NjYzMjQ= (base64)

造轮子本身没有对错之分吧。 基建部门需要做的是造好或者整合好一套可以提供给内部使用的轮子， 这个轮子最好简单、易用、高效、安全，这样就可以保证团队里的人可以基于你的轮子更简单、高效的产出。
最好有自己的逻辑闭环，可以把整套的基建串联起来，最终做到降本增效、稳定高效，这就是基建的价值。

不借

@wangxiaoaer 要摈弃原来三范式的思维， 反范式设计数据库字段，用字段冗余去满足一些业务需求。

用 Mongo 就要换思维了。 不要再想着外键、连表查询啥的。 全部放到业务里做，数据库只做数据存储。

你这应该 all in 算法啊，想不开搞啥后端啊。

if a!=nil ?

@fengsien99 很正常吧。 公司业务线多的话，每个业务线可以自由选择技术栈的。