我觉得是非常合适的，曾经在某短视频巨头写过一段时间 java，我对 java 在极限场景可以压榨的性能还有一些生态还是印象非常深刻的，但其实 go 对这些场景也可以不错的覆盖，让我觉得很实用的一些点还是资源占用可以很低，这是 java 比较难做到的，我司的大部分服务的 docker image 打包出来都可以在 40m 一下，运行时的内存占用也在 100m 左右，有状态的服务会略多，这对于业务刚起步的初创公司来说其实可以节省一大笔费用，同时也意味着你在单个节点上可以做的事情更多，如果你的场景是财大气粗的大厂，那这些确实算不上优点。

正常，我司一直这样，前端没人手只能自己上，不止写前端，运维的活好多时候也得自己干，edge 端的 ARM 程序也得自己写，为什么？因为要 deliver 产品，就不能让任何技术上的问题阻碍。

微服务架构本来就不应该去关联不属于你的服务的表，应该用接口的方式去通信，禁止 join 的做法没有错，前天刚看到我司四个 join 的语句，explain 出来连续四五个 nested loop，如果你能为你写的 join 语句担责，愿意赔钱，那没问题，不然就老老实实遵守公司的规则。如果你觉得你司的数据量就这么小，以后也涨不了多少，那你大可以跟你老板去说，辞职吧。

加个丰巢，没有人工客服，微信公众号只有机器人，官方电话转人工也没人接。。。

复杂 sql 大家看看文档都会写，问题是两个业务场景是不一样的，互联网公司的业务场景通常用户数较多，并发会比较大，企业应用的场景大部分可能只是一个公司内部的用户比较多，并发也较少，联表查询是可以接受的，在高并发场景下把大的数据库请求拆分成小的，是比较正常的做法，其次就是写在代码里比较容易改变，并且提供了较好的扩展性。

多站一站还是很有效的，中午可以多出去走一走

随便学学吧，Airbnb 用 flask 比较多，Superset 和 Airflow 都是 flask，优点就是比较灵活，做工具的话很不错。

除了 windows 相关的开发，我想不出来用 mac 有什么劣势。

最靠谱的就是用 nginx+ImageMagick 搞，用 java 调的话还是比较蛋疼。

搞后端反正搞不过 java，君不见国内比较早用 go 的独角兽都在转 java，中间件的话一票 go cncf 的质量都不如 apache 的众多 java 项目，浪潮褪去了才知道谁在裸泳，10 年也许还不够，让我们再看 10 年，看看 go 能发展成什么样。

你们用 java 写服务，不预热？？？

楼主过度敏感了，没那么复杂，一个电视厂商没心思给你搞这么多东西，不喜欢这些功能关掉就好了，又要它有智能功能又不让它连路由器。。。

DI 啊，跟服务端的 spring 作用一样啊，因为国外那帮程序员得写测试代码啊，所以需要 DI

你的环境有问题，重新配一下，我一个 monorepo 几万个 go 文件都没问题，目前用着还是很满意的

感觉明基的护眼系列都还可以，至于有人说 4k 更清晰更不费眼的，我觉得不一定，之前显示器由 2k 偶然跳到了 1080p，感觉眼睛舒服了很多，虽然看着模糊，但眼睛不累，我觉得每个人感受都不一样吧，看人，看得累了就休息休息，最主要还是从补充营养和休息入手吧

没必要过度设计，snowflake 已经是相当广泛应用过的 id 生成算法，碰撞不用考虑，对外暴露 id 加 salt 加密就可以了，只要不把原始 id 暴露出来就可以，等有人攻击你们系统了，也就有钱搞这些了

RocketMq 和 Kafka 的性能基线就不在一个水准上，Kafka 利用顺序读写已经把一个 MQ 的性能压榨到比较极限的水准了，超高的性能也带来了一些问题，每一个 topic 在硬盘上用一个 logfile 表示，通过顺序读写可以使性能非常高，但当多个 topic 的多个 partition 分布在同一台机器上时，原本的顺序读写就变为随机读写，partition 越多，随机就越严重，apache pulsar 解决了这个问题是使用 bookkeeper 做 store，这样做同时也降低了性能基线，业务需要很高的性能时，用 Kafka 没错，堆机器就行了，没钱堆机器时也不需要那么高的性能。

引流，涨粉，拉新。算是灰产，但利益庞大，很有钱景，新媒体行业的标准玩法。

@hardware 确实，一份价钱一分货，我的 16 年的 mbp 用了三年多没出过任何问题，除了有一次把水泼键盘上了，以为完了，结果放了一天又自己好了，从此稳定用了好几年。