后端标签是简历；
explain() 才是背景调查。1. 动机
应用经常把 family 标签变成规划器分支：「向量数据库」理应支持所有向量操作，或「SQL」理应共享一种文本排序规则。真实提供商会随操作、字段策略、版本、配置与实时资源而变化。 HeavenBase 通过 Context 局部的backend_type Registry 记录解析每个 Backend。静态标签描述候选角色；精确处理器记录、编译器输出与实时检查决定执行。工作区让提供商选择可检查，却不会假装一个标签能证明原生行为。
debug 预设对数据行使用 SQLite，并配有内存向量与搜索实例。它不需要外部服务，是推荐的首次运行方式。
2. 从 0.1.2.1 提供商矩阵中选择
协议兼容的选择器仍然是不同 Backend 身份。例如 Supabase 与 pgvector 使用 PostgreSQL 协议，却拥有不同的构造与放置行为。Milvus Lite 也不是 Milvus 服务器的别名。
可选提供商需要自己的 Python 包、凭据与可达服务。
sql extra 安装维护中的 SQL 驱动；full 安装当前平台可用的内置提供商客户端。
3. 从预设开始
4. 使用显式 Backend 映射
工作区局部名称是映射键；Registry 选择器位于每个type 中：
main、vec 或 search，而不是直接路由到提供商类型。把凭据保存在环境插值或显式进程配置中；公共诊断会省略认证值。
需要路径定位符时，本地文件提供商使用共享 file:// 定位语法。远程提供商把物理资源名称限定到工作区与 Backend 实例，让全新进程中的清理仍然有界。
5. 按策略放置字段
InlineColumn、SideTable、JsonField、SparseGramIndex、VectorIndex、InvertedIndex、GraphEdge 与 ExternalRef。注册会把意图与命名 Backend 实例、已安装放置 profile 一起解析。
SQL Backend 可以承载 SparseGramIndex，对短关键词数组做反向包含。显式 gram Backend 仍是窄兼容路线；新应用通常把 sparse-GRAM postings 与 SQL 行存储放在一起。
6. 检查标签、能力与具体计划
meta.tags。缺失可选标签定义时，原始声明会带着未解析诊断继续可见；声明不会被抹去。
全局能力描述已注册候选。工作区能力通过已配置 Backend 实例进行过滤。两者都不能代替具体查询计划：
handler_mode、回退原因、不安全原因与便携证明细节。
7. 了解提供商特定边界
- 独立 Backend 不会形成分布式事务。
- 本地 JSON 与 pickle 面向开发；把 pickle 视为可信本地数据。
- Milvus 向量字段必须为必填，因为它的数据行不能表示缺失的
FLOAT_VECTOR。 - 提供商排序规则与文本操作可能不同；除非不安全查询策略显式接受提供商语义，否则 HeavenBase 可能选择精确便携扫描。
- Pinecone 无法为所有无界归约证明穷举枚举。
- 本地文件与嵌入式提供商仍需要显式所有权与清理；
detached=True不会让其数据变成临时数据。 - 可达性、凭据、服务器版本与配额是实时事实，不是模块标签。
摘要
- Backend 类型名称标识候选项，而不是经过证明的执行。
- Preset 简化构造；显式映射与放置表达刻意选择。
- 标签负责描述，能力负责筛选，而
explain()报告具体路由。