无状态不是服务器真的不保存状态，而是客户端可以通过凭证在无感知的情况下从任何一台机器请求都能得到一样的结果。Session 不大的话每次直接带在 Request Body 中也未尝不可，我就见过很多服务把一堆状态数据塞在 Jwt 的 Claims 中来回倒腾的。Session 大的话就放在 Redis 集群，随用随拿。

先黑了数据库卖数据，再发勒索邮件，再扮演白帽子收取信息修复费，再举报自己售卖的数据拿感谢费，一鱼多吃 /:狗头。

@shadownet 钱是个大问题 /:sad

@WEBUG 还没有，晚上回去试一下，谢谢！

自己做着玩怎么都行，原生开发繁琐但专注，同时 Uniapp / Flutter 等平台和框架的开发成本未见得就比原生低。
要是准备长期浸淫只有原生一条路可以走。

没有，从初中玩游戏第一次充钱买好装备高兴地大喊之后，从赛尔号第一次把盖亚打下来高兴地在地上打滚之后，就再也没有狂喜的感觉了。我觉得我的感觉在钝化，人也在慢慢腐朽。

locate -cr 'path_to_your_folder'

喜欢普洱的话，大益 7572

@zhuangzhuang1988 我是同意的，毕竟我司出品。

@Rwing Java 相比 C# 确实会啰嗦很多，但不至于差别这么大，估计是用了体量不对等的框架和设计理念吧。大事有大框架，小事有小框架或者不用框架，而在人们写 Java 时习惯性地都用大框架（包括我自己）。

@acmore 格式乱了。

没有必要为了微服务而微服务，虽然有很多理论指导和论证，但是真正应用的时候大多都是趟泥地。当拆分的好处远大于不拆分的坏处时自然就会拆分，而很多情况下微服务都会显著增加开发和维护成本。项目首先还得是个 Monolith 或者至少是有演化成为 Monolith 的趋势，这个时候开始制定拆分策略应该是比较合适的，很多项目大概都活不到这个时候。当然大多数时候都是拍板者拍板，干活的执行。

表面是 Overdesigning, 实质是 KPI Oriented Programming.

之前的一个评论在在这再贴一下:

> 其实确实没有必要为了微服务而微服务，虽然有很多理论指导和论证，但是真正应用的时候大多都是趟泥地。当拆分> 的好处远大于不拆分的坏处时自然就会拆分，而很多情况下微服务都会显著增加开发和维护成本。项目首先还得是个 > Monolith 或者至少是有演化成为 Monolith 的趋势，这个时候开始制定拆分策略应该是比较合适的，很多项目大概都活> 不到这个时候。当然大多数时候都是拍板者拍板，干活的执行。

表面是 Overdesigning, 实质是 KPI Oriented Programming.