我今天手边这套 CAP Bookshop 模型里，最常被反复触碰的不是 Controller，也不是某个复杂的 UI 组件，而是一条条查询。Booage，也就是 CQL。在 CAP 项目里，我们经常一边写 service handler，一边写 SELECT、INSERT、UPDATE、DELETE，也一边把这些查询交给 CAP runtime 去转成数据库可以理解的 SQL，或者交给远程服务适配器去转成 OData 请求。CQL 的价值就在这里，它不是单纯照搬 SQL，而是把 CAP 里最核心的模型、关联、投影、事务和服务消费都放进同一套表达体系里。从开发体验看，CQL 很像一把有分寸的刀。写得简单时，它可以像普通 SQL 一样清楚；写到复杂业务时，它又能沿着 CDS association 导航，把 Books 和 Authors、Reviews、Orders 之间的关系表达出来。更关键的是，在 SAP BTP 上做 CAP 应用，代码最终往往要面对多种运行环境，开发阶段可能用 SQLite，本地测试可能接 HANA Cloud，集成阶段还可能消费远程 S/4HANA OData 服务。CQL 把这些差异隐藏在 CAP runtime 后面，让我们尽量站在业务模型层写查询，而不是一开始就陷在某个数据库方言里。拿最基础的读取说起，SELECT.from 是很多 CAP Node.js 项目里的高频写法。它可以查全部字段，也可以显式限制列，还可以通过别名把数据库字段映射成更贴近服务接口的名字。Bookshop 这类模型里，title、author_ID、price、stock 都很直观，现实项目里也一样，采购订单、销售订单、库存地点、供应商主数据，只要进入 CAP service handler，最先需要解决的通常就是如何读出刚好够