这是一个或许对你有用的社群 一对一交流/面试小册/简历优化/求职解惑欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料《项目实战视频》从书中学往事中“练”《互联网高频面试题》面朝简历学习春暖花开《架构 x 系统设计》摧枯拉朽掌控面试高频场景题《精进 Java 学习指南》系统学习互联网主流技术栈《必读 Java 源码专栏》知其然知其所以然这是一个或许对你有用的开源项目国产Star破10w的开源项目前端包括管理后台、微信小程序后端支持单体、微服务架构RBAC权限、数据权限、SaaS多租户、商城、支付、工作流、大屏报表、ERP、CRM、AI大模型、IoT物联网等功能多模块https://gitee.com/zhijiantianya/ruoyi-vue-pro微服务https://gitee.com/zhijiantianya/yudao-cloud视频教程https://doc.iocoder.cn【国内首批】支持 JDK17/21SpringBoot3、JDK8/11Spring Boot2双版本新来的同事 3 行代码写完了我一周的接口这个框架不是 SDK是把后端简化成「只写权限」决策矩阵什么场景能上、什么场景必须避开5 类核心能力一个 URL 搞定所有 CRUD权限模型才是这 3 行代码的真本体真正会让你掉坑的几件事一句话收口新来的同事 3 行代码写完了我一周的接口公司新来一个同事第一周就给了我一个暴击。我们做内容管理后台一张文章表Article发布、下架、修改、单查、批量改分类、列表分页、按作者查、按标签搜——按惯例8 个接口。我用 Spring Boot 写了整整一周——Controller、Service、Mapper、DTO、参数校验、单测每个接口一遍。新同事接过去给我看了他的代码——就 3 行MethodAccess public class Article { // 内容一般仅供表字段说明及客户端开发使用服务端不用的可不写 } // Verifier 中加这一行 accessMap.put(Article.class.getSimpleName(), getAccessMap(Article.class.getAnnotation(MethodAccess.class)));「8 个接口已经能用了。」他说。我看了一下 URL所有查询都是POST /get、所有写入都是POST /post、所有删除都是POST /delete——传不同的 JSON Body就能拿到不同的结果。整个项目里没写一行 SQL没写一行 Mapper更没写 Service 和 Controller。我从震惊到沉默——这 3 行代码替我写完了我一周的活。这背后是一个 17K Star、Tencent 出品的开源后端框架。它的设计哲学很反潮流在所有人讨论「怎么写后端更快」的时候它直接把「写后端」这件事抹掉了。基于 Spring Boot MyBatis Plus Vue Element 实现的后台管理系统 用户小程序支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能项目地址https://github.com/YunaiV/ruoyi-vue-pro视频教程https://doc.iocoder.cn/video/这个框架不是 SDK是把后端简化成「只写权限」很多人第一次看会以为是「类似 MyBatis-Plus 的 ORM 增强」——完全不是。它的定位更激进前端定义 JSON 请求结构后端只校验权限SQL 自动生成、执行、返回。打个比方传统 SpringBoot 后端这个框架增删改查后端逐个写接口后端不写前端传 JSON字段过滤DTO 类 MapStruct 转换前端 JSON 写column关联查询Service 拼接 / SQL JOIN前端 JSON 写id: /Article/authorId分页 / 排序接口参数前端 JSON 写count/order后端代码量1 张表 ≈ 100-300 行1 张表 ≈ 3 行仅权限说人话它把「后端写接口」这件事几乎抹掉了——后端的代码量从「业务接口实现」变成「只写权限规则」。国内技术圈把它拿来做内容管理 / 后台管理 / 数据中台前端查询的越来越多——它对原型期、内部系统、to B 配置型场景特别合适但生产业务系统能不能直接全量用后面会专门讲。它叫APIJSON由 Tencent 开源GitHub 18K Star、Gitee 6K Stargithub.com/Tencent/APIJSON。基于 Spring Cloud Alibaba Gateway Nacos RocketMQ Vue Element 实现的后台管理系统 用户小程序支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能项目地址https://github.com/YunaiV/yudao-cloud视频教程https://doc.iocoder.cn/video/决策矩阵什么场景能上、什么场景必须避开不是所有项目都能上。先按两个维度判断业务逻辑简单CRUD 为主业务逻辑复杂有事务 / 校验 / 风控内部系统 / 后台管理 / 原型APIJSON ✅✅甜区APIJSON 自定义 Controller 混用 ⚠️to C 业务系统 / 高并发APIJSON 严格权限 ⚠️要看 SQL传统接口 ✅别强上 APIJSON直接结论甜区内容管理后台 / 内部工具 / 数据查询型 to B / 原型期 MVP——后端开发量直接砍 80%。能用但要小心to C 业务里查询占比高的部分文章列表、商品列表、订单查询加上严格权限和column限制可以用。必须避开核心交易下单 / 支付 / 库存扣减、复杂业务规则风控 / 审批流 / 算分——这些必须传统 ControllerAPIJSON 接不住。最坑的误区是「APIJSON 要么全用要么不用」——正确姿势是混用CRUD 走 APIJSON业务逻辑走传统接口。3 行代码省 80% 的体力活剩下 20% 的核心业务该怎么写还怎么写。5 类核心能力一个 URL 搞定所有 CRUDAPIJSON 把所有 CRUD 操作压成 5 个 URLGET base/get 查询含列表、分页、关联、模糊搜索 POST base/post 新增含批量 POST base/put 修改含批量 POST base/delete 删除含批量 POST base/head 统计countURL 不变不同的 JSON Body 决定行为。下面拿「文章 作者 评论」这套内容管理场景的表来举 5 个例子。1. 单条查询「查 id 为 100001 的文章」{ Article: { id: 100001 } }返回{ Article: { id: 100001, title: Spring Boot 实战, authorId: 82001, status: 1, createdAt: 2026-04-26 10:00:00 }, code: 200 }2. 列表 字段过滤 条件「查所有已发布的文章只要 id 和 title 字段」{ Article[]: { Article: { status: 1, column: id,title } } }返回直接是个扁平数组不需要再处理嵌套结构。3. 关联查询核心能力「查文章列表 每篇文章对应的作者信息」{ []: { Article: {}, Author: { id: /Article/authorId } } }id: /Article/authorId表示「Author.id等于上一层Article.authorId」——这套语法替代了传统的 SQL JOIN ORM 关联映射。更复杂的三表关联——「查文章 作者 评论列表」{ []: { count: 10, page: 1, Article: {}, Author: { id: /Article/authorId }, Comment[]: { Comment: { articleId: []/Article/id } } } }一个 JSON 表达「文章列表10 条第 1 页 每篇的作者 每篇下面的所有评论」——这种结构传统 Controller 写至少 50 行。4. 批量更新「把 id 为 22 和 114 的两篇文章批量改到分类 5」{ Article: { id{}: [22, 114], categoryId: 5 }, tag: Article[] }id{}是个 IN 操作相当于WHERE id IN (22, 114)。5. 模糊搜索 函数「标题里含 MyBatis 的所有文章」{ Article: { title$: %MyBatis% } }title$是模糊搜索相当于WHERE title LIKE %MyBatis%。还有更多操作符操作符含义例子key{}IN / 范围匹配id{}: [1,2,3]key$模糊搜索title$: %Spring%key?正则匹配phone?: ^1[0-9]{10}$key引用赋值关联id: /Article/authorIdcolumn返回字段column: id,titleorder排序order: createdAt-,idgroup分组group: authorIdcount分页大小count: 10这套设计跟 GraphQL 思路类似但比 GraphQL 轻得多——不需要写 schema、不需要预先定义 Query 类型直接对着数据库表用。权限模型才是这 3 行代码的真本体前面说「3 行代码 8 个接口」那 3 行代码本质是权限注册——APIJSON 真正在校验的是这套权限模型。MethodAccess注解里给每种操作配置允许的角色MethodAccess( GET {UNKNOWN, LOGIN, ADMIN}, // 文章可以让游客也看 POST {LOGIN, ADMIN}, // 登录后才能发文章 PUT {OWNER, ADMIN}, // 只有作者本人或管理员能改 DELETE {OWNER, ADMIN} // 只有作者本人或管理员能删 ) public class Article {}五个内置角色角色含义UNKNOWN未登录LOGIN已登录普通用户CONTACT该资源相关用户评论作者、收藏者等OWNER该资源所有者文章的作者本人ADMIN管理员不满足权限直接返回 401登录后角色匹配则通过权限校验失败的细节会写明「哪张表 哪个操作 当前角色 需要的角色」——调试体验比手写 Spring Security 的 401 友好得多。OWNER角色尤其值得记住——它会自动校验「资源的 authorId / userId 字段是否等于当前登录用户」。这是「文章作者只能改自己的文章」这种典型业务的零代码实现。真正会让你掉坑的几件事按踩到概率从高到低排坑一N1 查询是原生病最常见关联查询id: /Article/authorId看起来很香但底层是逐条查 Author 而不是 IN——文章列表 100 条就是 100 次 Author 查询。新人接入第一个月一定会踩。做法用Author[]列表语法 id{}批量引用APIJSON 会自动转成 IN 查询。生产里关联场景永远用列表语法。坑二SQL 注入靠权限规则兜底不是天然防的常见APIJSON 自动生成 SQL但column/order这些字段如果直接透传前端值理论上还是能注入。官方在这层做了正则白名单但你必须显式开——Verifier配置里有disabledColumns/disabledOrderColumns这些选项。做法生产环境必须配白名单 column字段过滤敏感表密码 / 卡号 / 手机号禁用前端访问。坑三复杂业务逻辑硬塞进 APIJSON 是灾难常见见过有人用 APIJSON 做下单接口——不要这么干。下单涉及库存扣减、价格计算、风控、事务、消息——这些都需要 Service 层强塞 APIJSON 后续维护噩梦。做法APIJSON 管 CRUD业务逻辑走传统 Controller Service两套系统并存不冲突。坑四前端 JSON 协议没文档化少见但维护时痛APIJSON 的 JSON 协议很灵活但灵活的反面是难维护——前后端没有强 schema 约束新人来了不知道某个字段叫什么、字段格式是什么。短期没事项目跑半年后接手的人想杀人。做法用 OpenAPI / Yapi 这类文档工具把核心 JSON 协议显式记下来前端封装一层 SDK把常用查询包成函数。一句话收口APIJSON 不是「让后端没了」是把后端工作的重心从「写接口」转到「定义权限和业务规则」——CRUD 这种重复劳动让框架做人去做真正需要思考的部分。它在内部系统、后台管理、原型期是真神器——3 行代码省 80% 的体力活但在 to C 核心业务系统里它是辅助工具不是主框架——核心交易、复杂业务、强风控该写还得写。工程取舍很简单——别把 APIJSON 当万能药也别因为「后端有点危机感」就拒绝它。它是在合适场景里把后端解放出来的工具仅此而已。那位新来的同事的「3 行代码」之所以让我傻了一周不是他的代码多牛——是他选对了场景。同样的 3 行代码用在下单接口上就是灾难用在内容管理后台上就是降维打击。选工具的能力比写工具的能力更重要。GitHubhttps://github.com/Tencent/APIJSONGiteehttps://gitee.com/Tencent/APIJSON欢迎加入我的知识星球全面提升技术能力。 加入方式“长按”或“扫描”下方二维码噢星球的内容包括项目实战、面试招聘、源码解析、学习路线。文章有帮助的话在看转发吧。 谢谢支持哟 (*^__^*