迁库最磨人的不是搬数据，是方言怎么转换

迁库最磨人的不是搬数据，是方言怎么转换信创、降本、换 PG，数据库迁移已经不稀奇了。数据搬过去往往有现成工具；真正耗人的是 SQL / DDL 文本层——类型、自增、函数名、标识符引号，每种库写法都不一样。几百张表靠手改，改完还不敢保证目标库能跑：验证成本常常比改写还高。jkit-sql 做的是把这

对外接口自动裁掉 敏感字段：聊聊列级权限与脱敏

对外接口自动裁掉敏感字段：聊聊列级权限与脱敏数据合规（个保法、GDPR）时代，"谁能看哪些列"是硬需求。但脱敏代码往往散落在每个接口里：if (role == ADMIN) ... else mask(...)。这一篇讲怎么用 AST 改写，在不改业务 SQL、不污染原句的前提下

1200 条复杂 SQL，4 大数据库通吃：一套能直接跑的业务分析语料库

1200 条复杂 SQL，4 大数据库通吃：一套能直接跑的业务分析语料库电商 / 金融 / 人力，50 张真实表 + 约 8 万行数据，导入即跑，拿走不谢。做数据分析、写 SQL 的同学，多少都经历过这个瞬间——收藏夹里躺着一堆「SQL 面试题」「窗口函数大全」「100 个必会查询」，真到了业务里要

不想为了自动建表硬塞一个 Hibernate？这套方案零编译依赖、注解都不用改

启动服务时按实体自动建表，注解零改动复用实体驱动建表听起来不新鲜——Hibernate 的 ddl-auto、不少脚手架都能干。真正卡住的人，多半不是"会不会生成 CREATE TABLE"，而是：项目根本不在 Hibernate / JPA Provider 体系里，却已经有一

14 个业务场景，一个 SQL 解析器全干完

14 个业务场景，一个 SQL 解析器全干完标题里写「网关」，是因为审计、路由、Wall、租户改写最常落在这一层；但同一套能力也覆盖迁移、分页、实体建表、格式化、遗留模板——凡是要读懂、改写、校验 SQL 文本的地方都用得上。真正卡住的往往不是「能不能执行 SQL」，而是「能不能处理别人给过来的 S

SQL 不是字符串：一个零依赖解析器能替你干的六件事

SQL 不是字符串：一个零依赖解析器能替你干的六件事SQL 不是字符串：一个零依赖解析器能替你干的六件事一、五分钟写出来的代码需求很朴素：发布前扫一遍订单模块的所有 SQL，列出它们碰了哪些表，评估改动影响面。第一版实现长这样：Pattern p = Pattern.compile("(?