JWT 和 Session ID 一起出现本身就挺奇妙的……
一个用于无状态，一个用于有状态。

给老人 15 应该够用了吧？除非你说出使用场景。

有些插件会提供一个可配置的解释器路径给你，没提供的话估计就没什么办法了

@fyxtc #5 大部分人应该还是会先选择微信吧……好像是现在通过接口让用户直接授权手机号变难了，但有些应用为了合规又必须记录才会搞成这样。

@ldp940622 #3 对，所以我现在可能会选择手机号+验证码

人事开始强调考勤和绩效，出各种复杂制度，一般都是冲着所谓降本增效去的。
但大多数时候并不能增效，把忍不了的逼走就算降本了。

GPL3 ？好评

我记得作者来站里做过推广，怎么搞成这样了？

优点当然也是有的：

1. 可以练手，不然你下一份工作的简历怎么办？
2. 容器化管理起来确实容易，哪怕我就俩服务，用 k8s 也方便些，至于你说消耗的资源……那是老板的钱，又不是我的。
3. 战未来，万一火了呢？
4. 微服务不仅能拆分大型软件，还能方便拆分团队，如果一个项目有很多个组参与，使用微服务会比写成单体然后让大家工作在同一个仓库下容易些……同理，如果前提是没几个用户，进程内通信和跨进程通信相比那点优势也微不足道。至于额外的复杂度，k8s 也基本能解决，没几个用户的项目又能复杂到哪儿去呢？

额外建一张表存 B2 和对应的统计值，每次插入在同一个事务里往主表插入并让副表统计值+1 。

这个升华部分的批判毫无道理……就好像在批判 Java 这样有 GC 的语言让程序员的平均水平降低了一样……
事实上确实降低了，但它同时降低的还有这个行业的门槛，最终的结果是提高了整个行业的生产效率，而效率才是市场真正追求的东西。
至于顶尖人才变少，这个不知道有没有具体数据支撑？也许这些人的绝对数量并没有什么变化，给你这种感觉是因为他们占行业总人数的比例减少了。

需求简单的话，Ruby 的 RoR 或 Py 的 DRF 了解一下

都微服务了，要不整个 k8s 吧……也算 Go 技术栈，后面你说的这些需求甚至可能不怎么需要写代码就能解决了。

@ben548 呃，不需要的。虽然不知道你使用什么技术栈，但正常点的语言实现异步处理都不会很困难，无论你用线程协程还是其他进程（消息队列也属于跨进程异步）。

只能说明他们实现了同一组接口