十九世纪末，经典物理遇到过一个相当尴尬的问题。按照当时已经相当成熟的理论去计算黑体辐射，频率越往紫外区域走，理论预测出来的辐射能量竟然会无限增大。实验结果显然不是这样。公式没有算错，实验也没有做错，真正出问题的是支撑那套计算方法的理论框架。后来，这个问题有了一个很有名的名字，紫外灾难。Max Planck 引入能量量子化之后，现代量子理论的大门才逐渐被推开。SAP 从传统 ABAP 开发走向 SAP Fiori、RAP、ABAP Cloud 和 Clean Core 的过程中，也会碰到一些颇有这种味道的问题。不是某一行 ABAP 代码明显写错了，也不是某个 OData 请求直接失败，而是几种单独看都很合理的机制叠加以后，产生了非常反直觉的结果。其中一个很典型的问题，就是 SAP Fiori elements List Report、BTP ABAP environment、Custom Entity、远程 OData 服务、本地扩展表以及分页机制同时出现时发生的数据丢失。这种现象可以称作 SAP 世界里的 paging catastrophe，也就是分页灾难。SAP Community 中已经出现了开发者对这一问题的完整记录，场景正是 SAP BTP ABAP environment 中的 Custom Entity 通过后端 OData 服务读取数据，同时还需要利用 BTP 本地字段进行过滤。乍看之下，这不过是一个分页问题。真正深入到执行过程里，会发现它其实同时牵涉数据归属、过滤下推、OData 查询语义、RAP unmanaged query、无状态请求以及跨系统数据联邦。问题的背景很符合现在越来越常见的