通用层级结构CSV转嵌套JSON的Python实现思路与元数据设计指导

一、Hierarchy Attribute Map 元数据的设计优化 #

核心设计原则：彻底将映射规则从执行逻辑中剥离，杜绝硬编码残留，适配任意层级深度的转换需求，结构设计不需要引入复杂的自定义DSL，普通Python字典存储即可，后续要迁移到YAML/JSON配置也非常方便，可参考三个核心模块设计：

• 每个层级节点的规则定义需拆解为三类独立要素，避免逻辑耦合：
  • 层级唯一匹配规则：明确CSV中哪一列的值用于判定同一层级的重复实体，比如一级节点靠dept_id列判重，相同值的所有CSV行统一归到同一个部门节点下
  • 层级属性映射规则：定义当前节点下需要输出的JSON键与CSV列的对应关系，支持直接列值映射、常量值填充两种常见场景，不需要写死字段名
  • 子层级挂载规则：明确当前节点下，子层级输出的JSON键名（比如部门节点下的团队列表键名固定为teams），以及对应子层级的规则引用
• 预留扩展位支持异常场景处理：比如遇到匹配列值为空时，是跳过该行、填充默认值，都可以在元数据里定义，不需要修改核心转换逻辑

三级场景的元数据结构示意（仅为结构参考，非可运行代码）：

{
  "root_node": "层级规则A",
  "层级规则A": {
    "match_col": "公司ID",
    "attribute_map": {"公司名称": "company_name"},
    "child_key": "departments",
    "child_rule": "层级规则B"
  },
  "层级规则B": {
    "match_col": "部门ID",
    "attribute_map": {"部门名称": "dept_name"},
    "child_key": "teams",
    "child_rule": "层级规则C"
  },
  "层级规则C": {
    "match_col": "员工ID",
    "attribute_map": {"员工姓名": "emp_name"}
  }
}

二、通用转换逻辑的实现思路（解决核心逻辑卡壳问题） #

核心思路是用逐行锚点挂载的递归逻辑替代硬编码的多层嵌套循环，避免为固定层级写死循环，这套逻辑没有绑定CSV输入场景，只要能把数据源读成行字典列表，不管是CSV、Excel、还是数据库查询结果，都可以直接复用，步骤可参考：

1. 预处理阶段：读取CSV为纯字典列表，每一行对应一个{列名: 列值}的结构，这一步不做任何嵌套处理，仅统一列值类型（比如把CSV读出来的字符串型数字转成数值，避免匹配时类型不一致导致的重复节点问题）
2. 节点初始化阶段：按照元数据定义的最高层级规则，预先提取所有不重复的根节点，每个节点初始化时自动建好对应的属性字段、预留好子节点的空列表
3. 逐行遍历挂载阶段：每处理一行CSV数据时，从最高层级开始顺着元数据的层级链逐次锚点定位：
   • 取当前行在当前层级匹配列的值，在已构建的对应层级节点列表里找匹配的实体，找不到就按元数据规则新建节点
   • 定位到当前层级的节点后，继续沿着元数据定义的子层级规则，在当前节点的子列表里找下一层级的匹配实体，直到遍历到最末层级
   • 定位到最末层级的节点后，直接按属性映射规则填充字段即可完成该行的处理

• 关键避坑点：
  • 不要采用“先按每层分组、再逐层拼接嵌套结构”的实现方式，遇到跨层级空值、同一CSV行跨多个层级实体的场景时，很容易出现结构错位
  • 节点创建时必须提前初始化所有子节点的空列表，不要等到遍历到子层级时临时创建键，减少键不存在的类型报错
  • 匹配键的判重逻辑要统一封装成通用方法，不要在每一层循环里单独写判重判断

三、现有硬编码脚本的平滑迁移方法 #

不需要完全重写现有脚本，只需要把硬编码里写死的列名、JSON键名、层级挂载关系，全部迁移到上述的元数据结构中，把原来写死的三层循环替换成上述的递归挂载逻辑即可，迁移成本很低。 #

内容的提问来源于stack exchange，提问作者Error_2646