在数据处理和接口对接中，经常需要把内存里的树形数据转成带缩进的 XML 文本。如果层级固定，用循环加字符串拼接还能应付；一旦结构动态变化、深度不可预知，递归就是最直观也最容易维护的写法。它让每一层节点使用同一套处理逻辑，只在进入子节点时增加缩进量，退出时闭合标签。
为什么用递归处理嵌套 XML
嵌套 XML 的本质是树结构：每个节点可能有零到多个子节点，子节点之下还可能继续嵌套。这种自相似特征正好匹配递归函数的定义，也就是函数在其内部调用自身处理规模更小的同类问题。相比用显式栈或队列模拟，递归代码更贴近数据形状，读起来就是“处理当前节点，然后对每个孩子再做同样的事”。
缩进是这类输出的另一个要点。缩进量通常由节点深度决定，递归调用时把当前深度加一传给下层，就能在生成开标签前补上对应数量的空格或制表符。这样无论数据有几层，缩进都不会乱。如果不使用递归，你得自己维护层级计数和缓冲区，代码里会散落大量判断和累加逻辑，后期改结构很容易引入 bug。
基础递归实现示例
下面用 Python 演示一个最简单的递归函数，把字典和列表混合的树形数据变成带缩进的 XML 字符串。字典表示带属性的节点，列表表示重复子节点或文本集合。
def build_xml(node, depth=0):
indent = ' ' * depth
if isinstance(node, dict):
# 取出标签名和属性
tag = node.get('tag')
attrs = node.get('attrs', {})
children = node.get('children', [])
attr_str = ''.join(' %s="%s"' % (k, v) for k, v in attrs.items())
lines = ['%s<%s%s>' % (indent, tag, attr_str)]
for child in children:
lines.append(build_xml(child, depth + 1))
lines.append('%s</%s>' % (indent, tag))
return 'n'.join(lines)
else:
# 文本节点直接返回缩进后的内容
return '%s%s' % (indent, node)
data = {
'tag': 'root',
'attrs': {'version': '1.0'},
'children': [
{'tag': 'user', 'attrs': {'id': '1'}, 'children': ['Alice']},
{'tag': 'items', 'children': [
{'tag': 'item', 'children': ['Book']},
{'tag': 'item', 'children': ['Pen']}
]}
]
}
print(build_xml(data))
运行后得到的文本中，每一层都比上一层多两个空格，标签严格闭合。这个例子里 build_xml 在遍历 children 时调用了自己，并把 depth 加一，从而自然形成缩进。属性拼接也放在同一函数里，避免在外层做格式假设。
需要注意的是，Python 的递归深度默认有限（通常一千层）。对于特别深的配置树，可能触发递归异常。此时可以改用迭代版，或者把系统递归限制调大，但更稳妥的是在解析数据前先做深度校验，对异常深的结构做扁平化或分片处理。
带转义和自闭合节点的完善版
真实场景里，文本可能包含 &、< 这类字符，直接写进 XML 会破坏结构。递归函数应当统一在文本出口做转义。同时，没有子节点的标签可以输出成自闭合形式，减少冗余。
def escape_text(text):
return str(text).replace('&', '&').replace('<', '<').replace('>', '>')
def build_xml_v2(node, depth=0):
indent = ' ' * depth
if isinstance(node, dict):
tag = node.get('tag')
attrs = node.get('attrs', {})
children = node.get('children', [])
attr_str = ''.join(' %s="%s"' % (k, escape_text(v)) for k, v in attrs.items())
if not children:
return '%s<%s%s/>' % (indent, tag, attr_str)
lines = ['%s<%s%s>' % (indent, tag, attr_str)]
for child in children:
lines.append(build_xml_v2(child, depth + 1))
lines.append('%s</%s>' % (indent, tag))
return 'n'.join(lines)
else:
return '%s%s' % (indent, escape_text(node))
sample = {
'tag': 'note',
'children': [
{'tag': 'to', 'children': ['Tom & Jerry']},
{'tag': 'empty'}
]
}
print(build_xml_v2(sample))
上面代码在属性值和文本中都过了转义，空节点输出为 <empty/>。因为转义逻辑只写在 escape_text 里，后续若需支持 CDATA 也只需改这一个函数，不影响递归主干。
从结构看，递归版把“怎么处理一个节点”和“怎么进入下一层”清晰分开。新增节点类型，比如注释或处理指令，只要在 dict 分支里加判断即可，不必触动缩进与递归调度部分。这种局部修改能力，是相比手撸循环最大的工程优势。
与其他方案的对比
如果不写递归，也可以用标准库如 xml.etree.ElementTree 先建对象树再序列化。这种方式更严谨，自带转义和格式控制，但面对动态拼装、条件裁剪等需求时，仍要在内存里先建完整树，不如直接递归吐字符串灵活。下面是简单对比：
| 方式 | 代码量 | 动态性 | 风险点 |
|---|---|---|---|
| 手写递归 | 少 | 高，可边遍历边决定输出 | 深层栈溢出、需自管转义 |
| ElementTree | 中 | 中，先建树后写 | 内存占用、API 学习成本 |
| 模板引擎 | 多 | 低，结构固化于模板 | 嵌套模板难维护 |
选择时可根据数据来源判断：若是数据库游标逐步读出、且层级由数据内容决定，递归拼接最省力；若是固定报表格式，用库或模板反而更稳。无论哪种，理解递归缩进原理都有助于排查输出格式问题。
小结与注意
递归构建带缩进嵌套 XML 的核心，是把“节点处理”与“深度传递”解耦：函数只关心当前层怎么写，缩进由参数控制，子层交给自我调用。实践里别忘文本与属性转义，并对超深数据设防。掌握这个思路后，类似 YAML、JSON 美化输出也能用同一套模式快速改写。