不同长度列表字典转换为多类别汇总表格方法

直接上结论：两种方法均可将键值长度不等的列表字典转换为宽表，缺失值会自动填充0或'x'，根据实际需求选择即可。

在日常数据分析工作中，经常遇到这种嵌套结构：字典的每个键对应一个类别列表，而各列表长度不一致。例如 {'A': ['CATEGORY 2'], 'B': ['CATEGORY 1', 'CATEGORY 2'], 'C': [], 'D': ['CATEGORY 3']}，需要将其展平为“宽格式”汇总表：每行一个键，每列一个类别，有则标记1或'x'，无则留空。如果直接使用 pd.DataFrame.from_dict(..., orient='index')，会发现pandas默认按位置展开，无法按类别语义对齐，空列表会导致列错位。

下面介绍两种方案：一种简洁高效，一行代码即可完成；另一种灵活可控，适合复杂场景，读者可根据需求选择。

方案一：使用 str.get_dummies() 实现语义清晰的宽表转换——一行代码搞定

import pandas as pd

response = {
    'A': ['CATEGORY 2'],
    'B': ['CATEGORY 1', 'CATEGORY 2'],
    'C': [],
    'D': ['CATEGORY 3'],
}

# 核心思路：把每个列表用 '|' 拼成字符串，然后扔给 get_dummies() 自动拆分
out = (
    pd.Series(map('|'.join, response.values()), index=response.keys())
    .rename_axis('ITEM')
    .str.get_dummies()
    .reset_index()
)

print(out)

运行结果如下：

  ITEM  CATEGORY 1  CATEGORY 2  CATEGORY 3
0    A           0           1           0
1    B           1           1           0
2    C           0           0           0
3    D           0           0           1

如果需要显示为 'x' 而非数字1，可在最后添加 .replace({0: '', 1: 'x'})。注意：这会将数值列转换为字符串类型，后续无法进行数值计算，仅适用于展示场景。

方案二：字典推导结合 pd.DataFrame.from_dict()——逻辑直观，完全可控

# 构造中间字典：每个键对应一个 {类别: 'X', ...} 的字典
intermediate = {
    k: {v: 'X' for v in lst} 
    for k, lst in response.items()
}

out = pd.DataFrame.from_dict(intermediate, orient='index') \
    .rename_axis('ITEM') \
    .reset_index() \
    .fillna('')  # 空值变空字符串，保持 'X' 标记风格

print(out)

输出结果（使用 'X' 标记）：

  ITEM CATEGORY 1 CATEGORY 2 CATEGORY 3
0    A                       X         
1    B          X          X           
2    C                                 
3    D                                X

关键注意事项与技巧

• str.get_dummies() 仅接受字符串类型的Series，空列表 [] 经过 '|'.join([]) 后变为空字符串 ''，get_dummies 会自动为其生成全零行，行为稳定可靠。
• 方案二中的 fillna('') 必须在 reset_index() 之后调用，否则索引列也可能会被填充为空字符串。
• 如果类别名称包含空格、斜杠等特殊字符，get_dummies 默认可以处理。但若后续用于机器学习特征，建议提前标准化，例如使用 .str.replace(r'\s+', '_', regex=True) 替换空格。
• 两种方法都能自动提取所有唯一类别作为列名，无需手动去重和排序。如需固定列顺序，可在最后添加 reindex(columns=['ITEM', 'CATEGORY 1', 'CATEGORY 2', 'CATEGORY 3'])。

总结：如果追求快速原型和简洁代码，推荐方案一；如果需要更灵活的定制（例如支持多值权重、自定义标记符）或更易于调试，方案二更为合适。在生产环境中，更推荐方案二，因其可控性更高。