正经学一遍肯定是好的，问题在于，代价极大。

CSS 是个排版系统，不是 UI 系统。他的原始设计是为排版而研发的，所以它有很多看起来很怪异的地方，比如那个著名的，特性不正交问题。

而我们现在利用 CSS，百分之 80 的是时间是在写 UI，这导致了一个问题，大部分前端开发只需要研究 flex 这种专门为补强 UI 排版而被新开发出来的布局，其它的可以不管。

但是这带来了另外一个问题，就是相当多的前端开发其实根本不了解 CSS，他们对 CSS 的理解大部分都远不如他们对 JS 的理解，这导致他们几乎没办法解决 20%的排版问题——很多前端拿到一个别人开发的，有问题的排版布局时，他们根本无法找到原因，他们最常见的处理方式是把人家写的布局删了，然后重新自己写一个。。。

看了我上面的描述，你应该明白 CSS 这东西水有多深，我觉得 CSS 的水比编程语言的水深多了，再加上现在 web 调试工具在 CSS 调试上可以说一点都不好用——因为 CSS 的特性导致调试工具在页面出现问题的时候根本无法直接指出原因，得靠开发人员自己分析，这和一般编程语言可以靠断点和日志直接定位问题所谓难度高出了两个级别。

综上所述我认为 CSS 虽然值得研究，这是人类至今为止开发的使用最广泛的布局(UI)系统，但是它有很多问题，很多的历史包袱，导致真正能把这个系统理解穿并能灵活运用的人其实很少。CSS 本质是背书并且查表，和一般的编程是基于逻辑，流程，判断，有很大的不同，所以这更加大了这玩意的学习难度

钱不多而已，别信程序员口嗨，他们真正要的是钱多，而且不加班。而且不加班和钱多之间，大部分优先选择钱多的。
所以我从来不看程序员哭诉 996，不加班的公司有的是，他们嫌钱少不去而已

@ClassicOldSong 请你弄清楚，没有任何人当着你的面说“我平庸我有理”；而是你用你口中的“不平庸的标准”过滤了用户，反过来又嫌弃没人来 star 你的项目。我只是告诉你，这个世界上平庸的人是多数，如果你看不上这些平庸的人，那你就不要在意平庸人世界你发生的事情——比如那些刷星的，买流量；你一方面又在意这些，又树立门槛标准过滤，还怪罪别人不来舔你是没有追求是“我平庸我有道理”。

到底谁不讲道理？

@ClassicOldSong
vue 没有中文文档是什么时候的事情了?

搞技术的当然要对自己严格要求，要努力学习英文以看到更多的资料。这没错。但是这不是你用来要求别人的理由。更不是轻飘飘的说懂英文是基础技能。

你既然已经说了，你的服务对象是分人的，有些人不是你的服务对象（英文这道坎能拦住多少人你心里有点数吗）。那你为啥要对不是你服务的这些人 star 了别的库耿耿于怀呢，你不在意他们，为何要在意他们造成的结果？

我说你没点自觉真的没说错。

你要呆在高高在上的技术象牙塔里，就别在乎外面的事情；要在乎外面的事情，就不要高高在上，这个世界永远是平庸者更多

@ClassicOldSong
你的 github 我仔细上下的认真的找了一下。

然后我发现连中文的 readme 文档都没有。。。然后我打开你贴的技术文章链接，发现也是英文。。。

然后你跑到一个中文论坛上抱怨你的仓库没人用。。。

我觉得，你是不是缺少一点自觉。

记得在别处看到过，google 的搜索引擎有个核心程序是 C++写的，编译出来得到的可执行文件高达 1GB ；以至于编译时的 GCC 超出内存占用，以至于那个开发组不得不魔改 GCC 来完成编译。

我个人觉得，抽象也好，各种设计模式也好，过于学术，过于完美。而现实不是完美的，所以现实的东西总是看起来这里有缺点，那里有缺点。所以我觉得，程序员尤其不能处女座

其它的我不评论，npm 这个玩意有啥资格来评价 maven

sql 已经非常简单了，我觉得你重新定义 SQL 真的没有意义，SQL 没有被 NoSQL 干跨已经说明了自己的生命力如何。

最后，复杂度问题的存在是各种通信协议的更新解决不了，无论你管这通信协议叫 REST 还是 GraphQL 都没意义

@luzhh 链路追踪和日志中心的成本真高，动不动就是几台服务器，或者要上 ELK 做查询。我其实很早就想把自己的服务拆分化，后来一看我才几台服务器啊。我要拆了得上链路中心和日志中心，搞不好在这上面的服务器比我的应用服务器都多，实在是尴尬。

@Tarkky 微服务本质是用空间换了复杂度，用体积膨胀，人员膨胀的方式把问题分而化之了。所以如果你的组织度跟不上的话，你解决不了问题，反而问题更多

1.把 java 语言的大部分特性撸一遍，你有 C#基础，java 不难的，当初 C#就是对标 java 的产物，加了一堆语法糖，导致大部分从 C#来 java 的人第一眼会觉得 java 很简陋。
2.oracle jdk 你自己用，oracle 还会给你发律师函吗，怕毛
3.spring boot 其实是 spring 官方在 spring 越来越膨胀后，为了让新手快速上手开发应用，搞出的一个类似模板应用一样的东西。
你只需要记住 spring 的灵魂是依赖注入就行了，需要什么功能，或者自定义什么功能，预先让 spring 载入变成了一个受 spring 管理的对象，然后你就可以把这个对象轻松的注入到任何你需要的地方。比起你自己 new 轻松一些，仅此而已

@yeqizhang
@EminemW
@Jooooooooo

因为这玩意如果不初始化，那么序列化为 json 后就是一个 null，因为某些前端限制，很难处理 null，它们希望这个东西至少序列化是个 {}

为啥要“积极解决”？这公司是你的吗？

@micean 我这个，文件并没有丢失，我去看过，文件还在，但是 spring-boot-devtools 提前加载导致它“错误”了这个 class

@fewok 到目前为止，根本不存在通用型的 Service Mesh，否则这东西早就风靡起来了，就是在大厂，他们的 Service Mesh 也是和他们的业务高度耦合的；只能在他们的应用场景下，实现“自动调度和参数调整”。换一个场景，就要傻眼和重新调整。

我非常理解后端开发的痛点以及一直以来都希望有一套系统能屏蔽掉大型系统的治理难题。让应用层真的“仅仅关注业务逻辑”。然而现实是，没有谁真正通用的做到这一点了。只能在有限的场景下近似的完成。