开始2025年悄然翻篇，回头回望，没有轰轰烈烈的高光时刻，只剩一身风尘与满心通透。工作和身体都折腾了一通,也慢慢想通了一些事情，那些当初觉得熬不过去的坎，现在看也都熬过来了。 工作这一年的工作轨迹，绕了不少弯路，从上家公司主动离职，在我工作这么多年里没几次主动离职。在那里我花了很多心思投入了很多心血，最后结果却不尽如人意。决定离职的时候，心里最多不是不甘而是错付，但也逼着自己想明白了：一份工作要是

前言在后端开发中，MySQL多表联查是支撑复杂业务查询的核心手段，但也是性能问题的重灾区——据统计，线上环境中近60%的慢查询都与不合理的多表联查相关。实际开发中，常被一系列核心问题困扰：多表联查到底连几张表最合适？为什么大家都推荐小表驱动大表？业务逻辑放在MySQL里还是业务服务中更好？查询数据时，该一次查大而全还是分批次查询？这些问题的本质，都指向MySQL的底层执行逻辑与业务场景的适配性。

前言现在AI在开发圈已经不是新鲜事了，还守着纯手动编码的老路子，很容易在效率上被拉开差距。以前的IDE智能提示、代码补全确实好用，但顶多算是“省点敲击次数”的辅助工具，没法从根本上提升开发效率和代码质量。 而现在像Claude、Gemini这类专注编码的模型，已经能成为真正的工作搭档——尤其是Agent智能体成熟后，它们不再是简单的问答工具，能理解整个项目的上下文，像同事一样分析问题、执行任务，还

前言在使用MySQL做业务开发的时候，经常会遇到多层嵌套的查询场景，为解决这类问题Mysql8.0提供了CTE（Common Table Expression，公共表表达式），在实际开发过程中如果子查询如果嵌套层级过多会形成查询黑洞，不仅编写时容易出错，后续维护人员需要从内到外逐层拆解才能理解逻辑。而CTE可以将每个层级的查询拆分成独立的CTE，逻辑顺序清晰，就像写代码时的函数调用一样。 使用CT

前言在.NET 开发中，垃圾回收（GC）是 CLR 提供的核心能力，它自动管理内存分配与回收，大幅降低了内存泄漏的风险。但GC 并非 “无成本”—— 回收过程中会产生 “Stop-The-World”（STW）暂停，频繁的 GC 操作会直接导致程序卡顿、CPU 占用飙升，尤其在大数据处理、高并发接口等场景下，GC 压力可能成为性能瓶颈。简单GC介绍 常见的 GC 不友好代码List 扩容带来的 G

前言FastEndpoints 是一个轻量级的 REST API 开发框架，它摒弃了传统的 Controller/Action 模式，是基于REPR(Request-Endpoint-Response)设计模式设计的API。性能与Minimal APIs 不相上下。对比传统 MVC 性能上要上不少。对于性能的要求高的微服务非常推荐。 REPR 设计模式FastEndpoints 摒弃 MVC 的「

前言很多时候我们在工作中总是忙而无效，多数的时间成本都被浪费，定义程序员的产出并不应该是写代码的效率。而是创造的价值和有效性。 当接到开发功能特性的时候，应该问问产品这些问题： 我们为什么要做这个特性，它会给用户或者公司带来怎样的价值？ 什么样的用户会用到这个特性，他们在什么场景下使用，他们又会怎样使用它？ 达成这个目的是否有其它手段？是不是一定要开发一个系统？ 上线后，怎么衡量它的有效性？

为什么需要在云时代,随着业务的不断发展和扩大,分布式的系统已经是大部分企业的首选，然而分布式也会带来一个都会遇到的问题，任何一个节点或者组件出现问题都可能会导致整个服务的雪崩。 对于服务雪崩的情况主要有两个解决办法，一个是快速的失败减少系统的复杂，也就是熔断、限流、降级，另一种是快速的扩容，增加服务的负载能力。需要注意的是熔断是被动感知故障的，并且熔断肯定会导致系统的抖动。 熔断生活中就有一些熔断

前言最近在公司参与一个七巧板的团队游戏，游戏规则其实很简单，但是前提是大家能有效的沟通并达成一致。最终以未能达成目标而结束，整个游戏让我意识到沟通是保证有效工作的前提条件，也是非常重要的一项工作技能，因此自己总结归纳了一些自己对于沟通以及如何沟通的感受和心得。 什么是沟通比较官方的说法:沟通是指运用语言、文字或一些特定的非语言行为（面部表情、肢体动作等），把自己的想法、要求、信息等内容传递给对方。

减少对学习的排斥峰值和终值。人们对一切人、事、物的感受，由峰值和终值两个因素决定。峰值是指这段体验中的最高峰，包括正向和负向。终值是指这段体验结束时给你的感觉。在学习中应该避免负向峰值的出现，艰难和轻松的任务穿插着去完成是保持愉悦和高效的重要方法，轻松的任务可以是休息，散步，听音乐，或者睡一觉。 避免负向峰值的几个方法： 在制定计划的时候，量力而行，不要制定完不成的计划。 一天内的计划种类不要太