Path 系统与 Query 机制 ​

1. 为什么 Path 是核心基础设施 ​

在 Formily 里，Path 不是辅助工具，而是模型主轴：

• 字段创建定位靠 path/address；
• setFieldState/query/validate/reset 都依赖路径匹配；
• 解构路径（如 [startDate,endDate]）用于前后端数据结构桥接；
• Schema 依赖声明（dependencies/target）最终也走路径查询。

2. @formily/path 的能力边界 ​

Path 支持：

• 普通点路径：a.b.c
• 通配与匹配表达式：*、分组等
• 相对路径语义
• 解构语法
• 路径级 getIn/setIn/deleteIn/existIn/ensureIn

核心特征是“路径解析 + 缓存 + 匹配评分”。

3. Query 的设计细节 ​

Query 在构造时完成匹配地址集合的计算，后续支持：

• take/map/forEach/reduce
• get/getIn/value/initialValue

两个要点：

1. 精确路径优先尝试 address，再 fallback 到 path 索引映射。
2. pattern 模式下支持批量匹配，便于写大规模联动逻辑。

4. address 与 path 双索引的价值 ​

Form.indexes[path] = address 这层映射使得：

• 开发者可以用“数据路径思维”查询字段；
• 内部仍保留节点绝对位置（便于结构化管理与层级关系）。

这对包含 VoidField 的复杂树结构尤其关键。

5. 解构路径的价值点 ​

解构路径（如 "[startDate,endDate]"）本质上是：

• UI 侧保持组件自然数据结构（如日期范围数组）；
• 提交层自动映射到后端偏好的扁平结构。

这不是简单序列化技巧，而是 path DSL 提供的建模能力。

可结合官方指南阅读：

• docs/guide/advanced/destructor.zh-CN.md

6. 常见误区 ​

• 误区 1：把 path 当字符串拼接，忽略匹配语义与相对路径规则。
• 误区 2：只理解 address，不理解 path，导致 VoidField 场景下读写偏差。
• 误区 3：数组项迁移只改 values，不改字段图状态（Formily 已内建处理）。

7. 可回答模板 ​

“Formily 的路径系统不是工具函数集合，而是整个模型寻址协议。
它把字段节点路径（address）和数据路径（path）分离，再通过 Query 做统一查询抽象，从而同时支持结构化 UI 管理和提交数据幂等。”