@yakumo520 确实啊，成都这环境

@nbhaohao 抱拳了老哥一起加油

@ChevalierLxc 抱拳了老哥

@qwzhang01 感谢老哥认可！这 8 年确实没干别的，尽琢磨这些底层轮子了。

我也一直觉得 GitHub 提交记录是比简历更有说服力的东西。虽然大专学历在 HR 筛选那关经常吃亏，但在懂行的大佬面前，代码是骗不了人的。

@wbd31 感谢大佬细看。确实，Spring 的代码门槛极高，不少 PR 是为了对标它的规范。但如果细看逻辑，里面也有不少是实打实的 Bug 修复和性能优化。

比如这个：PR #33156 。我发现 Spring 6.x 的 DefaultErrorResponseBuilder 在处理错误响应头时，居然有一个核心接口是空实现（ Empty Implementation ），导致开发者设置的 headers 全都被静默忽略了。官方审核后确认为 type:bug 并合入。

还有像 PR #30251 和 #30189 ，是对 SpEL 表达式引擎 的内存和执行效率优化。MethodParameter copy constructor 字段（ methodAnnotations ）复制丢失


研读源码、对标规范、修复 Bug ，这一套流程让我对工业级代码有了敬畏心。我真正的底层产出（如基于 ASM 绕过反射、自研高性能 ORM 引擎）都沉淀在 today-infrastructure 里，欢迎大佬多提意见！

@tuomasi 感谢大佬建议

@crynocry 哈哈，没办法，大专这块砖在很多大厂的招聘系统里确实是硬伤。系统初筛的时候规则定死了，很多时候 TL 可能压根没机会看到我的简历，就被后台自动挂掉了。

@orikey 确实，老哥 说得很透彻，HR 确实更倾向于“不出错”的筛选逻辑，毕竟大专在系统里确实是个硬伤。

我现在也是想找能直接对话技术的 TL 。毕竟能写 80w 行代码、给 Spring 提 PR 这种事，HR 可能没概念，但懂技术的大佬一眼就能看出门道。

如果有路过的大佬组里缺这种“硬核造轮子型”的，求带路。

@admin948 对哈 谢谢 我白天的时候再看看

再补一个具体的技术实现细节：关于框架的性能优化，我实现了一套 ASM-based MethodInvoker 。

在 WebMVC 的 Handler 调用和 ORM 属性映射阶段，我并没有直接使用 method.invoke()，而是利用 ASM 动态生成了包装类。

这样在运行期间，所有的反射调用都被转化成了原生方法调用。
这也是为什么单机压测能跑到 14.5w QPS 且平均延迟仅 1.5ms 的关键原因。
持久层（ EntityManager ）目前专注于 高性能单表映射，设计上追求极致的透明和低损耗，欢迎对底层性能感兴趣的大佬交流。