每个系统实际情况不一样，无法评价
简单场景犯不上用容器，复杂场景有时候容器也 hold 不住，需要用啥就用啥，用啥好使就用啥

污名化防御性编程，B 了
有一说一，不用故意不好好写，80%的开发正常写都是屎，99%的开发自己写完的东西自己都看不懂，更不用说别人

连续剧是吧？楼主和 HotSpot 内存占用的爱恨情仇
[Java 很强，但是 Java 的路还很长]( https://v2ex.com/t/950472)
[quarkus-graalvm 可以救 Java native 一命]( https://v2ex.com/t/1057699)
[果然吃内存，一个简单的 Java 程序就占用了 250M 内存]( https://v2ex.com/t/1055770)

可以理解楼主的心情，因为我年轻的时候也喜欢抠这些东西，什么内存占用什么 gc 时间什么线程池参数
所以还是建议把精力用在更有深度的地方，别天天跟这些玩具较劲

当前最新版本 14.5
新版本出来不第一时间升，先看看有没有爆出什么离谱 bug （比如说某个版本的 java 问题）再升

看到‘Java 内存没救了’的惊世论断，切个屏看了看正在运行一个上古 java 项目的十几台 16c64g 服务器，我陷入了沉思。HotSpot 内存利用率确实一般，Java 的语法也确实一般，但是作为团队作为企业 Java 够便宜 HotSpot 够稳定，这就够了

最后还是要说，去小区门口拿快递拖个露营车就行了，不用开 600 马力牵引头

羡慕楼主玩这么花还没人管

没看懂问题…
看不懂代码这类问题，建议直接把问题塞进代码注释
不明白‘为什么这么写’的地方，最好带上‘我觉得可以这么写’

想要落地和掌握 DDD ，需要：
1. 项目业务足够复杂：简单项目不是不能 DDD 但是相当于大炮打蚊子性价比差
2. 需求方对自己的业务有准确深入的认识：否则做的设计和业务实际情况和发展对不上，等于白做
3. 开发团队足够强力：开发脑子不够用理解不了领域模型一切白费

弄一套无刻的键帽
盲打就成了

首先，不管啥模型，最后决定交付效率和质量的都是人
神仙团队别说瀑布模型，整个倒立拉屎模型都能提前交付质量还贼高

然后，瀑布模型的主要问题是太死板，想象一下你的上游系统，过去半年都没动静，某一天突然拉出来 100 个接口让你接，换谁都难受
相比之下敏捷主要是小步快跑，避免步子太大扯到蛋，也因为步子小，受变更的影响也没那么大，也一定程度增加了无意义的变更数量

买过两个 2 代，一个坏了一个没坏
后来坏了的咸鱼卖了…

因为这个问题不定时有人说不是一直有人说

手感这玩意因人而异，只要你觉得是那就是
我也觉得这玩意有点微妙的延迟，但是不咋影响使用，甚至可以用来打炉石

嫌大就加参数限制最大堆呗，默认最大堆四分之一物理内存肯定大啊
我在服务器上跑的一个小定时任务，spring-boot 弄的，xmx32m 一样跑

不要小看了跑在高性能 SSD 上的数据库的性能啊

公开信息共享 excel
保密信息本地 excel
数字化的终点 excel

不懂 laravel ，但是
session 机制其实类似一种 key-value 结构，session 是 value ，key 由服务端生成给到客户端，客户端请求的时候带着 key ，服务端用这个 key 去找到 session
于是主要的点有这么几个：value 存哪里，key 存哪里，key 怎么传递
1. value 存哪里：分服务器端和客户端，服务器端分内存和持久化（进程内进程外），客户端主要就是 jwt
2. key 存哪里：浏览器的话要么很自然的 cookie ，要么 sessionstorage 之类，其他地方各有各的说法
3. key 怎么传，浏览器的话还是要么很自然的 cookie （但是相对的，可能对带来额带宽占用），要么自己塞 header ，其他地方还是各有各的说法

换个角度，常规 key-value 的，key 通常就是一个不容易重复的字符串，而 jwt 属于 key-value 一体，好处是好做无状态，坏处是 key 太大而且无状态


于是：
jwt 机制属于 key 和 value 一体存在客户端，请求的时候自己往 header 里塞的类型（当然放 cookie 里也行但是有点大），因为无状态且有点大，更适合内部服务间通信
而”加密 cookie“应该是最传统的，http 服务自带的 sesion 放内存，session-key 放 cookie 的模式，更加朴实无华适用范围更大

赞一个👍🏻，虽然已经肌肉记忆 esc 接切换输入法了