每次为内部报表、运营后台写一个简单的查询接口，都要经历 Controller → Service → Mapper 的全套套路，这不仅是体力活，更是对开发时间的浪费。原 crabc-api 开源项目近期正式更名为 ApiGo 并发布了 5.0.0 版本，它的核心思路非常直接：在浏览器里写 SQL，一键发布成 REST API，省去中间所有的模板代码。
多数据源直连：不搬数据，直接暴露服务
ApiGo 的定位是 API 接口开发平台与企业项目脚手架，但最亮眼的功能依然是 SQL2API。在实际的企业环境里，数据往往散落在不同类型的存储中。ApiGo 5.0 支持动态数据源，你可以同时接入 MySQL、Oracle、国产的达梦、分布式的 TiDB、时序库 DolphinDB、大数据的 Hive，甚至是 Elasticsearch 这种 NoSQL 引擎。
这意味着你不需要先把数据抽到同一个库里再做接口。业务方要查 Hive 上的离线报表，运营要查 MySQL 上的订单状态，你只需要在 ApiGo 后台配置好对应的数据源连接，即可独立对外提供服务。
动态 SQL 与标签：把条件查询收拢在一个接口
单纯的表查询往往不够，业务接口通常带有复杂的筛选条件。ApiGo 支持动态 SQL 和标签语法，这类似于 Mybatis 的体验，但直接运行在 Web 端。
你可以把入参映射到 SQL 的变量中，并通过条件标签控制 SQL 片段的拼接。这样，原本需要写五个不同接口来应对 status=1、type=A 等组合查询的场景，现在只需一个接口加一段动态 SQL 就能搞定。
此外，接口的发布状态完全可视化控制。开发完的接口一键上线，出问题了直接一键下线切断流量，不需要改代码、重新打包部署。配合平台自带的权限控制与代理功能，内部不同团队调用 API 的鉴权与路由也能在平台内闭环。
实战演练：5 分钟跑起一个订单查询接口
下面通过一个最小化实操，演示如何用 ApiGo 快速搭建一个带条件过滤的查询接口。
1. 启动 ApiGo 服务
首先通过 Docker 快速拉起 ApiGo 后台（请根据官方仓库最新镜像标签调整版本号）：
docker run -d \
--name apigo-server \
-p 8080:8080 \
-e DB_URL="jdbc:mysql://宿主机IP:3306/apigo?useSSL=false" \
-e DB_USER="root" \
-e DB_PWD="yourpassword" \
apigo/apigo-server:5.0.0
注意：这里 ApiGo 自身的元数据（接口配置、权限等）默认存入 MySQL，请提前建好数据库。
2. 配置业务数据源
登录管理后台（默认 http://localhost:8080），在「数据源管理」中添加一个指向业务订单库的 MySQL 数据源，命名为 biz_order_ds。
3. 在线编写动态 SQL 并发布
在「接口管理」新建接口，路径设为 /api/orders/query，选择刚才的数据源，在 SQL 编辑器中写入如下动态标签语句：
SELECT
order_id, user_name, amount, status, created_at
FROM t_orders
WHERE status = #{status}
#if($name)
AND user_name LIKE CONCAT('%', #{name}, '%')
#end
ORDER BY created_at DESC
LIMIT 100
这段逻辑的含义是：
- 必须传入 status 参数作为精确匹配。
- 如果请求中带了 name 参数，则模糊匹配用户名；没带则自动忽略该条件。
保存后，点击「上线」，接口即刻生效。
4. 直接发起 HTTP 请求测试
无需写任何 Java 或 Python 代码，前端或客户端可以直接请求：
# 仅按状态查询
curl "http://localhost:8080/api/orders/query?status=2"
# 组合状态与姓名模糊查询
curl "http://localhost:8080/api/orders/query?status=1&name=zhang"
返回的就是 JSON 格式的订单数据。从建表到出接口，全程无需打开 IDE。
选型建议：快是优势，但边界要清晰
ApiGo 这类 SQL2API 工具在特定场景下效率极高，但在引入前需要明确它的能力边界：
适合接入的场景： - 内部运营后台、BI 数据预览等以查询为主的场景。 - 需要快速对接多个异构数据源、做数据聚合透出的中台项目。 - 已有成熟数据库表结构，只需快速对外提供只读或简单写入 API 的遗留系统改造。
需要谨慎或不宜使用的场景： - 核心业务链路（如交易、支付），这些场景需要严格的事务控制、领域模型抽象与代码级单元测试，SQL2API 绕过了这些保障。 - 复杂的多表写入与状态机流转，动态 SQL 很难清晰表达跨表一致性逻辑。 - 直接面向外部公众的高流量 API，平台代理与动态解析层可能成为性能瓶颈。
风险提示： 把 SQL 编写权下放到平台前端，意味着非研发人员（如数据分析师、运营）也能发布接口。这极大提升了敏捷性，但也打破了代码审查的防线。建议在团队内建立规范：所有通过 ApiGo 发布的接口，其 SQL 脚本必须以截图或导出形式归档到 Git，纳入版本管控，避免线上出现无人知晓的“幽灵接口”。
ApiGo 5.0 的更名与升级，标志着这类低代码 API 搭建工具正在从个人玩具向企业脚手架演进。用好它的动态与多源能力，同时守住代码审查与架构分层底线，它就能成为提速内部交付的利器。