- 博客(16)
- 资源 (11)
- 收藏
- 关注
RSS订阅原创 Java Lambda 类型安全查询是怎么实现的？从字节码层面拆一遍
本文揭秘了Java框架如何将方法引用转换为SQL列名的底层机制。关键点在于：1）通过继承Serializable的函数式接口获取方法元信息；2）利用SerializedLambda解析方法名并转换为字段名；3）结合反射和泛型实现类型安全。这种方案解决了字符串列名存在的重构风险和IDE补全问题，通过自递归泛型保证链式调用的类型一致性。文章还探讨了联表查询时混用不同Bean的解决方案——提供两套独立接口分别处理单表和多表场景，在类型安全与灵活性之间取得平衡。整个过程涉及JVM底层机制、反射和泛型的高级应用，展现
2026-07-07 18:52:04
184
原创 不微调模型，只写 skill：我让 Claude 学会了一个它从未见过的框架
不微调模型，不喂训练数据，只靠一套 Markdown 文档，Claude 就能稳定写出它从未见过的自研框架代码。本文以 DLZ-DB 为例，完整拆解 Claude Code Skill 的设计思路与实践效果。
2026-06-11 23:00:28
362
原创 AI 能在垃圾代码里完成需求，但它正在疯狂燃烧 Token
AI 写业务代码之所以贵、反直觉，根本原因不在 AI 本身，而在于"给垃圾代码加需求"这件事天然就是逆天而行。本文揭示为什么同样的需求在不同代码库上花费的 Token 差 10 倍。
2026-06-11 22:02:55
190
原创 MyBatis-Plus、JPA、JOOQ 用了一圈后，我为什么还是自己写了个 ORM
这不是又一篇"XX 框架最好"的软广。这是一份选型笔记——记录我在不同项目里用过 MyBatis-Plus、Spring Data JPA、JOOQ 之后，为什么最后还是决定自己造了dlz-db
2026-05-31 09:53:22
331
原创 企业微信、飞书、钉钉 Webhook 接入，后端代码为什么总是越写越丑
Webhook 代码难看，很多时候不是因为“业务太复杂”，而是因为团队下意识地把“解析 JSON”当成一项低价值劳动，于是任它在入口层堆着长。可一旦系统接入的平台越来越多，这些入口代码就会变成维护成本。JSONMap 在这里的真正价值，是帮你把事件消费写回“简洁、短、清楚”的状态。让入口像入口，让业务像业务。这不只是代码风格问题，而是系统边界有没有被认真对待的问题。💬 你们项目里的 Webhook 入口层，现在还好吗？我观察到一种规律：Webhook 代码开始腐烂的标志是——入口层的。
2026-05-28 08:54:20
395
原创 生产慢 SQL，为什么总定位不到是谁执行的？
sql执行日志告诉你"有 SQL 慢"，不告诉你"谁让它慢" ，怎么办？试了好多种办法，终于找了个优雅的方案！
2026-05-27 23:32:55
333
原创 微信支付回调里，为什么一行 data.order.amount 胜过五层判空
问题是，处理复杂 JSON 这件事，在很多项目里总是被写成一种机械劳动。很多后端代码之所以显得笨重，不是因为业务复杂，而是因为我们把“取值”这件小事写得太费力了。> 在边界层，最重要的不是把所有结构完整复刻出来，而是把你要的字段拿准、拿稳、拿得清楚。它只是非常容易把一件本来很简单的事情，写成“读着累、改着怕、出了问题不好定位”的样子。如果一个团队把 JSONMap 用到领域层到处飞，那就不是工具的问题，是边界没守住。这样做的好处是，动态结构停留在边界，强类型继续留在业务核心。支付回调这种代码，位置很特殊。
2026-05-27 22:34:48
306
原创 写了 20 年 Java，我受够了 MyBatis 的 4 个瞬间
MyBatis 用了不下 10 年。它是个好框架，但有些痛点是真磨人。SQL 日志难定位业务代码；简单的crud200代码；新租户动态接入无解；数据库json属性其实很优秀，缺少有人用
2026-05-22 14:50:59
408
原创 Excel 导入导出，为什么总会变成重复劳动地狱？
后端工程师在处理Excel导入导出时面临的"扁平结构与多表数据库不对齐"问题，提出了一种基于Bean元数据的声明式解决方案。
2026-05-20 14:16:06
380
原创 Prompt 不是重点，团队代码规范才是
AI 编码质量的上限不在 Prompt，在代码库的一致性。模型拟合的是项目中的代码分布，规范统一比提示词技巧更关键。工具链归一、模式固化、命名统一，AI 自然产出稳定。
2026-05-17 14:12:40
338
原创 你的 API 正在悄悄拖垮 AI 的代码质量
让 AI 写 Python 一行搞定，写 Java 却动辄 17 行判空。问题在 API 形状的决定。本文用 4 条规则讲清楚:什么样的 API，会让 AI 写出更精准的优雅代码。
2026-05-12 18:09:19
232
原创 AI 写 Java 太啰嗦？我把 30 行 Map 判空压成 1 行，发现问题不在 Prompt
让 AI 少写 80% 样板代码：用 JSONMap 给 Cursor/Copilot 提供更好的编码上下文
2026-05-08 12:19:30
384
原创 做接口开发最烦的，是处理JSON那么一个无聊的事情，会打断你的心流
很多接口代码看起来复杂，不是因为业务复杂。而是因为：我们把“取字段”写成了一场结构解析工程。真正耗人的，不是第一次多写了几十行。而是接口一变，你就得回去重读那一大段旧代码，重新走一遍判空、强转、中间变量和上下文。这是一种重复、危险，而且几乎不创造新价值的劳动。更好的状态是：字段从哪里取，一眼能看明白；结构哪里变了，一眼能定位；业务哪里要改，注意力能立刻回到业务本身。连续思考的心流。关于接口对接这件事，你们遇到过最头疼的问题是什么？附：文中示例所用工具dlz-kit。
2026-05-02 06:35:46
327
原创 高级工程师的真正核心能力清单
高级工程师的核心能力体现在七个方面：系统思维能在复杂环境下把握边界与本质；工程实践确保代码质量和项目规范；性能与可靠性关注稳定而非炫技；架构判断力基于业务痛点选择方案；团队沟通注重技术说服与协作；持续学习平衡创新与实用；业务洞察力将技术决策与商业价值结合。本质在于用有限资源实现最大价值，关键在于定义问题而非简单解决问题。
2025-11-12 08:44:07
432
原创 高可用架构并不是所有人都需要掌握的，也不是高级程序员的必备基础技能
高可用架构的误区与实践权衡 高可用性是系统设计的非功能性目标，其实质是通过冗余资源确保部分组件故障时的服务持续性。当前行业存在过度追求高可用的现象，主要源于大厂示范效应、面试导向和简历美化需求。实际上，真正需要高可用的场景仅限于关键业务、高流量系统或严格SLA要求的情况。对多数企业而言，基本的容灾方案和扩展能力已足够。高级工程师的核心能力不在于构建复杂架构，而在于做出合理的架构选择权衡，包括可维护性、性能优化与成本效益的平衡。
2025-11-11 20:35:57
150
原创 分布式事务是只魔鬼：吃得多，拉得少
分布式事务，看似架构升级，实则复杂度陷阱。本文以技术讽刺笔法，讲清它为何“吃得多、拉得少”，以及更优雅、更现实的替代方案。
2025-11-11 20:27:41
287
RDPWrap 1.6，windows home版远程桌面服务。自动下载最新rdpwrap.ini
2022-05-13
hibernate4源码集合
2014-01-17
spring3源码集合
2014-01-17
struts2源码合集
2014-01-17
struts框架jar包
2008-07-11
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人