静态建模与动态建模——两种世界观的分歧与共生
不是功能列表的差异，而是两种世界观——确定性建立时机与驱动方式的全面碰撞。
世界是已知的、稳定的。在编码阶段，数据库表结构、实体类关系、字段类型、关联映射——这一切都已经明确。确定性在编译时就已经建立完毕，系统在一条铺设好的轨道上稳定运行。
世界是未知的、变化的。编程那一刻，你不知道明天会接入 MySQL 还是达梦，不知道表里有几个字段。确定性只能在运行时动态感知和适应。
传统 ORM 定位为终端业务系统的直接开发工具，业务模型在需求阶段就已定型。而 AnyLine 定位为中间层开发平台，其用户是"二次开发者"甚至"业务人员"，他们会在运行时动态创建表单、定义数据模型、接入新数据源——这一切都不能提前预知。"平台赋能用户"才是 AnyLine 发挥动态适配优势的真正场景。
ORM 的数据源在启动时已固定，表结构通过实体类映射完成。AnyLine 的数据源可在任意时刻由不同用户发起接入请求，系统在运行时动态感知变化、完成数据模型重构和查询适配。低代码平台用户拖拽一个表单控件，后台自动完成字段扩展——无需停服、改代码、重新部署。
ORM 假设表结构稳定。AnyLine 面对的是：今天的订单表 10 个字段，明天某业务线接入完全不同的数据源，字段名、类型、甚至数据库类型都变了。三层能力应对——动态结构管理（自动建表/扩展字段）、动态数据源管理、200+ SQL 方言自动转换规则。
ORM 操作的是实体类属性，元数据用完即弃。AnyLine 操作的是表结构、字段、索引、约束、数据类型、精度、默认值——这些元数据是可直接读写的"一等公民"。读出的数据不只是字段值，还带完整的元数据信息，上层应用可在不预知表结构的情况下完整理解和操作数据。
ORM 和 AnyLine 对"变化"本身的态度是根本不同的。
表结构改了是"数据库变更"，需要走迁移脚本、改 Entity、改 Mapper、测试、部署。整个工程体系都在抵抗变化、控制变化、最小化变化的影响。
表结构改了是"运行时事件"，系统自动感知、自动适应、不需要人介入。整个工程体系都在拥抱变化、消化变化、把变化变成系统可以自动处理的事。
这导致了两种完全不同的架构心智模型：
防御型心智模型
用强类型、编译检查、映射配置构建一道墙，把变化挡在墙外
吸收型心智模型
用元数据、动态感知、方言转换建一张网，让变化穿过但被完整捕获
选哪个不取决于哪个更好，而取决于你的系统面对的变化频率和破坏力。变化少且可控，防御型更划算；变化多且不可控，吸收型更划算。
ORM 的核心动作是"翻译"：数据库的世界是表和列，Java 的世界是对象和属性。每一条映射配置都是一次人工翻译。这个翻译有三个隐性代价：
数据库改了，Entity 必须同步改。一条列的变更可以穿透五层：
开发者在数据库世界和对象世界之间反复跳转。写 SQL 时想着表结构，写 Java 时想着对象模型，调试时两边对照。这种认知负荷在简单系统里不明显，在几百张表的系统里会显著拖慢开发速度。
对象模型和关系模型本来就不是同构的。继承、多对多、稀疏字段这些关系型特征，翻译成对象模型时总要削足适履。最典型的就是 EAV（Entity-Attribute-Value）模式——在数据库里很自然，翻译成 Entity 就变成了一堆 Map<String, Object>，强类型优势荡然无存。
AnyLine 的解法：元数据驱动本质上跳过了翻译环节。它不把数据库的信息翻译成对象模型，而是直接操作数据库结构本身。没有翻译就没有同步成本、没有上下文切换、没有表达力损耗。
"运行时/动态/元数据"三个维度，用信息论的语言重新表述：
ORM 在编译时确定一切，相当于提前获取了所有信息。AnyLine 在运行时才确定，相当于信息延迟到达。延迟不是缺陷，而是对"信息尚未存在"这一事实的尊重。你无法在编译时确定一个运行时才创建的表。
信息不是静态的，它随时间演化。ORM 假设信息不变，AnyLine 假设信息会变。信息变化的速度如果超过了人工同步的速度，静态建模就会崩溃。
ORM 只关注数据的值（字段值是什么），AnyLine 同时关注数据的元（字段是什么类型、多长、可不可空）。多一个维度，就多一层确定性。用维度的冗余对抗信息的不确定，这是元数据驱动的核心策略。
三个维度合在一起，就是：
在信息延迟到达、持续变化的环境里，用更高维度的信息来建立确定性。
这才是"那只猫"隐喻的精确含义。
从世界观到技术细节的全面对比：
| 维度 | 传统 ORM | AnyLine |
|---|---|---|
| 世界观 | 已知领域，世界是确定的 | 未知领域，世界是变化的 |
| 建模时机 | 编译时，编程阶段完成 | 运行时，动态感知和重构 |
| 驱动方式 | 对象驱动（实体类） | 元数据驱动（表结构本身） |
| 核心操作对象 | 实体类与属性 | 数据库结构、元数据（带类型、精度、约束等） |
| 数据源管理 | 配置固定，启动时确定 | 运行时动态注册、切换、注销 |
| SQL 生成 | 依赖手动编写或框架方法 | 自动生成并智能优化，200+ 方言转换规则 |
| 定位产品 | 终端业务系统（ERP/CRM/OA） | 中间层开发平台（低代码/数据中台/动态引擎） |
| 面向用户 | 应用开发人员 | 系统架构师、底层框架开发者 |
| 使用门槛 | 较低，易于上手 | 较高，需理解元数据驱动理念 |
| 灵活性 | 低，改动需改代码重新部署 | 极高，运行时热适应 |
| 类型安全 | 强类型编译检查 | 依赖运行时校验和设计规范 |
| 性能特点 | 简单 CRUD 开发效率高 | 复杂查询场景下内存计算耗时降至传统 ORM 数分之一 |
| 适用场景 | 业务模型固定、稳定运行 | 需求不确定、快速迭代、多源异构 |
| 团队协作模式 | 前后端契约驱动——先定义接口再开发 | 数据驱动——数据结构即契约，前端可从元数据自动推导 |
| 测试策略 | 编译时类型检查 + 单元测试 | 运行时元数据校验 + 集成测试（必须真实数据源验证方言转换） |
| 故障排查 | 类型错误在编译期暴露 | 动态问题在运行时才暴露，需要更完善的日志和监控体系 |
它们不是敌人。在一个完整的大型系统里，两者往往是共存的。
核心的订单、用户、支付这类稳定业务，ORM 依然是最佳选择——强类型带来的安全感和开发效率无可替代。
数据中台的多源接入、低代码平台的动态表单、异构数据库迁移同步、敏捷报表的灵活构建——这些需要面对不确定性的地方，AnyLine 的价值才能完全释放。
订单、用户、配置——业务逻辑定义了表结构，结构由开发团队控制，变化由版本迭代驱动
用户自定义表单、外部数据源、动态报表——表结构由最终用户或外部系统定义，开发团队无法预知和控制
最常见的错误：用 ORM 做动态场景，或者用 AnyLine 做稳定业务。前者会写出满屏幕的反射和动态 SQL，后者会丢失编译期安全保障且增加学习成本。工具没错，场景错了。
ORM 和 AnyLine 的区别不是"哪个功能更多"，而是"你在对世界做什么假设"。
假设世界是确定的
用 ORM
假设世界是不确定的
用 AnyLine
而真正的合理，是知道系统的哪部分确定、哪部分不确定，然后在边界上画出那条线。