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

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

不想为了自动建表硬塞一个 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("(?

正则抠 SQL 翻车之后：聊聊解析器这件事

正则抠 SQL 翻车之后：聊聊解析器这件事做过 SQL 审计或上线影响面评估的，大概都试过一招：正则抠 FROM / JOIN。Pattern p = Pattern.compile("(?i)(?:from|join)\\s+([a-zA-Z0-9_`.]+)");Matche