## 1. 理解JSON与TXT的本质差异和转换前提 JSON和TXT看似都是“文本文件”，但它们承载信息的方式截然不同。我刚入行那会儿，就曾把一个嵌套三层的用户订单数据直接`str()`转成TXT，结果打开一看全是`{'user': {'profile': {'name': '张三', 'age': 32}, 'orders': [...]}}`这种密不透风的字符串——根本没法快速定位字段，更别说给运营同事做简单统计了。后来才明白：JSON是结构化数据的**交换格式**，强调可解析性；TXT是纯文本的**展示载体**，强调可读性。转换不是简单地“换后缀”，而是要把树状结构“摊平”成线性内容。 关键在于明确你的使用场景。如果你只是想备份原始数据、保留完整结构，那用`json.dumps(data, indent=2)`生成带缩进的TXT就足够了——我常在调试时这么做，一眼就能看清哪层嵌套出了问题。但更多时候，比如把API返回的用户列表导出给销售团队做电话跟进，你就需要“人眼友好”的排版：姓名、手机号、注册时间各占一行，中间空一行分隔不同用户。这时候就得手动控制格式，而不是依赖`str()`的默认输出。另外要注意编码问题，特别是中文字段。我踩过最深的坑是没指定`encoding='utf-8'`，结果导出的TXT用记事本打开全是乱码，而用VS Code看却正常——后来查证是Windows记事本默认用GBK解码，必须显式声明UTF-8才能跨平台通用。 还有一点容易被忽略：JSON里可能包含`None`、`True`、`False`这些Python特有值，而TXT里得转成`null`、`true`、`false`才符合通用规范，或者按业务需求写成“未填写”“已启用”这类中文描述。这决定了你不能无脑调用`str()`，而要根据字段语义做映射。比如用户状态字段是布尔值，直接写`True`对销售同事毫无意义，写成“激活中”才真正有用。 ## 2. 基础转换流程与代码实现细节 最常用的转换流程分三步：读取JSON → 解析为Python对象 → 格式化写入TXT。这个流程看着简单，但每一步都有实操细节。先说读取环节，`json.load()`要求文件必须是合法JSON格式，但现实中常遇到末尾多逗号、单引号代替双引号等问题。我建议加个异常捕获，避免程序直接崩掉： ```python import json try: with open('data.json', 'r', encoding='utf-8') as f: data = json.load(f) except json.JSONDecodeError as e: print(f"JSON解析失败，错误位置：第{e.lineno}行，第{e.colno}列") print(f"错误信息：{e.msg}") exit(1) except FileNotFoundError: print("找不到data.json文件，请检查路径") exit(1) ``` 解析后的`data`类型决定了后续遍历逻辑。如果JSON是数组（如`[{"name":"张三"},{"name":"李四"}]`），`data`就是Python列表；如果是对象（如`{"users":[{"name":"张三"}]}`），`data`就是字典。很多人卡在这一步——看到字典就懵了。其实很简单：先用`print(type(data))`和`print(list(data.keys()))`确认结构，再决定从哪一层开始取数据。比如上面的嵌套字典，你要导出users列表，就得写`data['users']`。 写入TXT时，`open()`的模式选择很关键。`'w'`是覆盖写入，适合生成新报告；但如果你要追加日志，就得用`'a'`模式。另外，`write()`不会自动换行，必须手动加`\n`，这点新手常忘。我习惯用`print()`函数替代`write()`，因为`print()`默认换行，还能用`sep`和`end`参数控制分隔符： ```python with open('output.txt', 'w', encoding='utf-8') as f: for user in data['users']: # 用print写入，自动换行，字段间用制表符分隔 print(user['name'], user['phone'], user['reg_time'], sep='\t', file=f) ``` 这样生成的TXT用Excel直接打开就能正确分列，比空格分隔更可靠。注意`file=f`参数把print输出重定向到文件，这是比`f.write()`更简洁的写法。 ## 3. 处理复杂嵌套结构的实用技巧 真实业务中的JSON往往像俄罗斯套娃：用户信息里嵌地址，地址里嵌经纬度，订单里嵌商品列表，商品里还有规格参数。直接`str(item)`只会得到一坨无法阅读的字符串。我的经验是分层处理：先提取顶层关键字段，再对嵌套部分做针对性展开。举个具体例子，假设JSON长这样： ```json { "report_date": "2024-05-20", "summary": {"total_users": 127, "active_rate": 0.83}, "users": [ { "id": 1001, "name": "王五", "contact": {"phone": "138****1234", "email": "wangwu@example.com"}, "orders": [ {"order_id": "ORD-001", "amount": 299.0, "items": ["iPhone15", "AirPods"]}, {"order_id": "ORD-002", "amount": 59.0, "items": ["USB-C线"]} ] } ] } ``` 如果要导出用户联系信息，我会这样写： ```python with open('contacts.txt', 'w', encoding='utf-8') as f: f.write(f"报表日期：{data['report_date']}\n") f.write(f"总用户数：{data['summary']['total_users']}，活跃率：{data['summary']['active_rate']:.1%}\n\n") for user in data['users']: f.write(f"【用户ID】{user['id']}\n") f.write(f"【姓名】{user['name']}\n") f.write(f"【电话】{user['contact']['phone']}\n") f.write(f"【邮箱】{user['contact']['email']}\n") # 展开订单：每个用户下所有订单合并成一行 order_lines = [] for order in user['orders']: items_str = "、".join(order['items']) order_lines.append(f"{order['order_id']}({order['amount']}元)：{items_str}") f.write(f"【订单】{'；'.join(order_lines)}\n") f.write("-" * 50 + "\n") # 分隔线 ``` 这里的关键技巧是：用`join()`把列表转成字符串，避免循环内多次`write()`导致格式错乱；用中文标点和符号（如【】、；、-）提升可读性；对数字字段用格式化字符串（如`{:.1%}`）自动转百分比。另外，`items`字段是列表，直接`str()`会带方括号，而`"、".join(order['items'])`能生成“iPhone15、AirPods”这样自然的中文顿号分隔。 对于更深层嵌套，比如要导出所有订单的商品明细，可以写个递归函数，但我一般用`jsonpath-ng`库来定位。比如`parse('$.users[*].orders[*].items[*]').find(data)`能一键提取所有商品名，比手动写多层for循环清晰多了。不过小项目没必要引入新依赖，手写逻辑反而更可控。 ## 4. 针对不同业务需求的定制化输出方案 转换不是技术炫技，而是解决实际问题。我根据过往项目总结了三类高频需求，每种都对应不同的TXT输出策略。第一类是**数据校验场景**，比如测试工程师要对比前后端返回的JSON是否一致。这时需要逐字段比对，所以TXT必须严格对齐。我的做法是用`json.dumps()`加固定缩进，并按键名排序： ```python # 生成可比对的标准化TXT with open('normalized.txt', 'w', encoding='utf-8') as f: normalized_json = json.dumps(data, indent=2, sort_keys=True, ensure_ascii=False) f.write(normalized_json) ``` `sort_keys=True`保证键顺序一致，`ensure_ascii=False`让中文正常显示，这样用Beyond Compare这类工具能清晰看到哪一行有差异。 第二类是**运营分析场景**，比如把用户行为日志转成表格供BI工具导入。这时需要CSV风格的TXT，字段用英文逗号分隔，字符串加双引号防逗号冲突： ```python import csv with open('analytics.txt', 'w', newline='', encoding='utf-8') as f: writer = csv.writer(f) # 写表头 writer.writerow(['user_id', 'event_type', 'timestamp', 'duration_sec']) # 写数据行 for event in data['events']: writer.writerow([ event['user_id'], event['type'], event['time'], event.get('duration', 0) # 用get()防字段缺失 ]) ``` 注意`newline=''`参数，这是Python CSV模块的坑：不加的话Windows下会多出空行。 第三类是**客户交付场景**，比如把订单详情生成PDF前的TXT草稿。这时要模拟纸质文档效果：添加页眉页脚、章节标题、金额右对齐。我用字符串格式化实现： ```python with open('invoice.txt', 'w', encoding='utf-8') as f: f.write("=== 订单发票 ===\n\n") f.write(f"订单号：{data['order_id']:<20} 日期：{data['date']}\n") f.write(f"客户：{data['customer']['name']:<20} 电话：{data['customer']['phone']}\n\n") f.write("商品清单：\n") f.write("-" * 50 + "\n") for item in data['items']: # 金额右对齐，总宽10字符 price_str = f"¥{item['price']:.2f}" f.write(f"{item['name']:<30} {price_str:>10}\n") f.write("-" * 50 + "\n") total = sum(item['price'] for item in data['items']) f.write(f"{'总计':<30} ¥{total:.2f}\n") ``` 这里`<30`和`>10`是Python的字符串对齐语法，让排版像真发票一样整齐。实际项目中，我还加了`datetime.now().strftime('%Y年%m月%d日 %H:%M')`动态生成打印时间，客户觉得特别专业。 ## 5. 常见问题排查与性能优化建议 转换过程最常见的报错是`UnicodeEncodeError`，尤其在Windows上。根源是系统默认编码和文件编码不匹配。我的解决方案是统一用`encoding='utf-8-sig'`，这个编码会在文件开头加BOM标记，确保记事本也能正确识别UTF-8。另外，大文件处理时别一次性读入内存。我处理过2GB的JSON日志，用`json.load()`直接内存溢出。改用`ijson`库的迭代解析： ```python import ijson # 逐个解析users数组中的对象，不加载整个文件 with open('big_data.json', 'rb') as f: parser = ijson.parse(f) # 或者更简单的：用ijson.items获取特定路径的值 users = ijson.items(f, 'users.item') with open('result.txt', 'w', encoding='utf-8-sig') as out_f: for user in users: out_f.write(f"{user['name']}\t{user['email']}\n") ``` `ijson`支持边读边解析，内存占用稳定在几MB。另一个坑是JSON里的特殊字符，比如换行符`\n`或制表符`\t`，直接写入TXT会导致格式错乱。我在写入前会做清洗： ```python def clean_text(text): if not isinstance(text, str): return str(text) # 把换行和制表符替换成空格，防止TXT格式崩溃 return text.replace('\n', ' ').replace('\t', ' ').strip() # 使用示例 f.write(clean_text(user['address']) + '\n') ``` 最后是性能问题。实测下来，对10万条记录，用`print()`写入比`f.write()`慢15%，因为`print()`有额外的格式化开销。但如果追求极致速度，可以用`sys.stdout.write()`配合`sys.stdout.flush()`，不过日常项目完全没必要，可读性更重要。我现在的标准流程是：小文件（<10MB）用基础`json.load()`+`print()`，大文件用`ijson`，所有字符串走`clean_text()`预处理，编码统一`utf-8-sig`——这套组合拳跑了三年，没出过一次线上事故。