Pandas如何解析JSON数据为表_利用json_normalize函数扁平化数据

pandas.json_normalize 这个函数，说起来挺有意思的——很多人以为它能一键把嵌套 JSON 拍扁成表格，结果往往发现列名变成了一串带点的“火车”（比如 profile.address.city），真正棘手的问题却一个都没解决。字段缺失怎么办？列表嵌套怎么炸开？多层结构怎么拆？答案其实都藏在参数组合里。

record_path：列表嵌套的“开关”

想象一下，JSON 里有个 "orders": [{"id": 1, "item": "book"}, {"id": 2, "item": "pen"}]，你期望它变成两行数据对吧？但默认情况下，json_normalize 直接把它整个塞进一列里，根本不会自动展开。这时候就得靠 record_path 来告诉它：“把这个列表里的每个元素拆成单独一行”。

• 如果源数据是一个字典，订单藏在 data['user']['orders']，那就传 record_path=['user', 'orders']
• 如果源数据是字典列表，每个元素都有 'items' 字段，就传 record_path='items' 或者 record_path=['items']
• 不提供 record_path 时，函数默认把整个 data 当作记录列表——这只能处理最外层就是 [{}, {}] 的简单情况

meta：别让父级字段“走丢了

一旦用了 record_path 去提取子记录（比如订单），父级数据里的用户 ID、时间戳这些信息默认不会自动跟着过来。怎么办？用 meta 参数把它们“提上来”。

• 要保留 user_id 和 created_at，直接传 meta=['user_id', 'created_at']
• 如果字段藏在嵌套路径里，比如 profile.name，可以用字符串形式 meta='profile.name' 或者列表形式 meta=[['profile', 'name']]
• 某些记录里 profile.name 可能缺失，这时候必须加 errors='ignore'，否则你会看到一个 KeyError
• meta_prefix 也是个好帮手：设为 'user_'，那提上来的 user_id 就变成 user_user_id 列，避免和子记录里的字段重名

sep 和 max_level：控制“拍”的深度

默认分隔符 sep='.' 会把 {"a": {"b": {"c": 1}}} 变成列名 a.b.c，看着挺直观？但麻烦在于，万一 API 返回里真的有一个叫 "a.b" 的 key，那就乱套了。更稳妥的做法是换分隔符，比如 sep='_' 得到 a_b_c，导出到数据库或 BI 工具时兼容性更好。

max_level 则用来控制展开的深度。只想拿到 profile 这一级，不想管 profile.address.city？设 max_level=1 就够了。超出层级的嵌套会被保留为字典或字符串类型——既不会报错也不会丢数据，这个细节很容易被忽略。

errors='ignore' 不是万能药，预处理才是王道

很多人以为加上 errors='ignore' 就能处理所有缺失情况，其实它只对 meta 里声明的路径生效，对 record_path 本身毫无作用。

• 如果 record_path=['results', 'data']，但某条记录里根本没有 'results' 这个 key，照样会抛 KeyError
• 如果 record_path 指向一个 None 值（比如 "orders": null），函数直接罢工，不会跳过那条记录
• 安全做法是预处理：用类似 pd.json_normalize([x for x in data if x.get('results') and x['results'].get('data')]) 的过滤逻辑，把脏数据提前筛掉，比硬扛错误可控得多

嵌套 JSON 的“扁平化”从来不是一次调用就能搞定的。最常被偷懒跳过的一步是：先 print(json.dumps(data[0], indent=2)) 看清第一项的结构，再动手配 record_path 和 meta——而不是对着报错信息反复试参数。这个习惯养成了，后面能省下不少时间。