企业官网建设流程全解析

1. 再聊游戏测试里的JSON，这次当成一门硬功夫来练

我做了几年游戏测试，最深的体会是：这行当早就不是“点点点”就能混下去的了。尤其是接触到接口测试、配置校验、日志分析这些活儿之后，你会发现有个东西几乎无处不在——JSON。客户端发个请求是JSON，服务器返回个奖励是JSON，策划配的表导出来是JSON，连自动化测试的测试数据也常常是JSON。可以说，不懂JSON，游戏测试的很多活儿你都干不踏实。

有人可能觉得，JSON不就是个数据格式嘛，有什么好学的？说实话，这种想法我也曾经有过，直到有一次因为少了一个字段的处理，导致线上活动发放奖励时大面积出错，我才彻底明白：JSON数据处理这门基本功，看起来简单，里面的坑是真不少。这不仅关乎代码能不能跑通，更关乎数据在各个环节之间流转的时候会不会变形、丢失、搞错类型，甚至直接干崩整个服务。

这篇内容主要围绕游戏测试工程师在Python方向上的JSON数据处理展开。我会把JSON的基本概念、Python内置的json模块、游戏测试里常见的处理场景、以及我在实际工作中踩过的坑和排查思路，全部拆开来讲。不管你是刚入门Python的测试新人，还是已经写了一段时间脚本但没系统梳理过JSON处理的同学，这篇内容应该都能帮你补上一些盲区。毕竟，“8周通关Python”这个目标里，JSON数据处理绝对是绕不过去的一关。

2. JSON凭什么成为游戏测试的“通用语言”

2.1 从一次接口排查说起

先讲个具体的场景。有一次我做活动接口的联调测试，客户端上报玩家完成了某个任务，服务器返回的数据大致长这样：

{ "code": 0, "msg": "success", "data": { "player_id": "10086", "task_id": 5023, "reward": { "gold": 500, "diamond": 20 }, "finish_time": 1710000000 } }

这段JSON看起来很简单，但你要真正去校验它，就涉及不少细节：player_id到底是字符串还是数字？reward.gold的取值范围是多少？finish_time是秒级还是毫秒级时间戳？如果服务器把code从0改成200，你的测试脚本能不能敏锐发现？

这就是JSON数据处理在游戏测试中的日常——它不仅是一种数据交换格式，更是客户端和服务器之间约定的“契约”。你理解了这份契约，才能写出真正有价值的校验逻辑，而不是跑一遍、看个“通过”就完事。

2.2 JSON的核心结构：对象与数组

JSON全称是JavaScript Object Notation，虽然名字里带着JavaScript，但它早已成为跨语言通用的数据交换格式。它的核心结构就两种：对象（Object）和数组（Array）。

对象是用花括号包裹的一组键值对，键是字符串，值可以是任意合法JSON类型。数组是用方括号包裹的一组有序值。这两种结构可以任意嵌套，所以它能表达的数据模型非常灵活。

我经常用一个生活化的类比来解释：JSON对象就像是一个填写好的“个人档案表”，每个字段都是表上的一个栏目；JSON数组就像是一排“档案袋”，你可以从里面抽出任意一份来看。游戏里的背包数据、排行榜数据、任务列表，本质上都是各种“档案袋”套着各种“档案表”。

理解了这个基础，你就能明白为什么游戏服务器特别钟爱JSON——它足够灵活，策划要加个新字段，服务器不用改表结构，直接在JSON里多塞一个键就行；它也足够直观，人类能直接读懂，调试起来比二进制协议友好太多了。

2.3 游戏测试中JSON存在的典型位置

根据我这几年的经验，游戏测试工程师和JSON打交道的地方主要集中在以下几块：

• 接口测试：绝大多数游戏的后端接口都采用JSON作为请求和响应的数据格式。登录验证、背包查询、商城购买、任务领取，全都是一来一回的JSON报文。
• 配置表校验：很多游戏的配置表会导出成JSON格式给客户端用。策划改了数值，测试需要校验配置的正确性，比如技能ID是否重复、物品价格是否合理、掉落概率加起来是否等于1。
• 日志数据分析：游戏运行过程中的行为日志、报错日志，很多也以JSON格式记录。测试需要从海量日志中筛选出关键信息，定位问题根因。
• 自动化测试数据：用Python写接口自动化测试时，测试用例的输入数据、期望结果、环境配置，通常都用JSON文件来管理。
• 封包协议模拟：在弱网测试、异常测试中，你可能需要手工构造或篡改JSON报文，模拟客户端发一些畸形数据，看服务器能不能兜住。

这些场景里，你光会“看”JSON远远不够，必须能在Python里熟练地读写、转换、校验JSON数据。这也是“JSON数据处理”作为独立一课存在的根本原因。

3. Python内置json模块：先啃下这块硬骨头

3.1 json.dumps与json.loads的一来一回

Python的json模块是标准库，不需要额外安装，直接导入就能用。处理JSON就两个最核心的方向：一是把Python对象转成JSON字符串，叫序列化；二是把JSON字符串转成Python对象，叫反序列化。

对应到代码上，就是两个最常用的函数：json.dumps()负责把Python的字典、列表等对象转成JSON字符串，json.loads()负责把JSON字符串解析成Python的字典、列表等对象。

import json player_info = { "player_id": "10086", "level": 30, "vip_level": 5, "items": ["sword", "shield", "potion"] } json_str = json.dumps(player_info, ensure_ascii=False, indent=2) print(json_str) parsed_data = json.loads(json_str) print(parsed_data["player_id"]) print(type(parsed_data))

这里有一个非常关键的参数——ensure_ascii=False。如果你不设置它，json.dumps()默认会把所有非ASCII字符转成\uXXXX形式的转义序列。中文会变成一长串\u73a9\u5bb6这种，不仅肉眼没法看，写进日志文件里也是一团乱麻。我做测试的时候，所有落盘的JSON文件几乎都会加这个参数，就是为了保证可读性。

indent=2是格式化参数，让输出的JSON字符串带上缩进，层级清晰。调试的时候特别好用，但如果你要压缩JSON以减少传输体积，那就得反过来用separators=(',', ':')来去除多余空白。

另外要注意json.loads()的解析结果——JSON里的true、false、null会分别转换成Python的True、False、None。反过来，Python的True、False、None也会被序列化成JSON的true、false、null。这个对应关系一定要记牢，不然很容易在数据比较的时候翻车。

3.2 类型对应关系：一张表说清楚

Python和JSON的类型不是一一对应的，尤其是元组、集合这类JSON里根本没有的类型，直接序列化会报错。我整理了一张在实际工作中最常用的对应表：

这里要特别提醒几个点。第一，Python的set集合不能被直接序列化，你得先转成列表。第二，json.dumps()在遇到float('nan')或float('inf')时，默认会输出NaN和Infinity，但这两个东西不是标准JSON的一部分，有些解析器根本不认，所以如果你要把数据发给其他语言的服务端，最好提前处理。第三，json.loads()可以传一个parse_constant参数来拦截NaN、Infinity这些非常规值，但在游戏测试的场景里，我更建议你做后置校验，确保上游给的数据本身就不带这些东西。

3.3 读写文件：别用open+read再手动解析了

很多新手在处理JSON文件的时候，会写成这样的代码：

with open("config.json", "r", encoding="utf-8") as f: content = f.read() data = json.loads(content)

这样写没错，但不够优雅。更直接的做法是用json.load()和json.dump()，它们直接对接文件对象：

with open("config.json", "r", encoding="utf-8") as f: data = json.load(f) data["new_version"] = "1.2.0" with open("config_modified.json", "w", encoding="utf-8") as f: json.dump(data, f, ensure_ascii=False, indent=2)

注意函数名差了一个s——不带s的是跟文件对象打交道，带s的是跟字符串打交道。这个细节看起来不起眼，但我在带新人的时候发现，几乎每个新人都会在某个时刻把json.load和json.loads混着用，然后报出一堆奇奇怪怪的错误。

还有一点务必谨记：读写JSON文件一定要指定encoding="utf-8"。在Windows环境下，如果不指定编码，open()默认使用系统编码（通常是GBK），遇到中文内容极容易报UnicodeDecodeError。这个问题我在Windows上踩过太多次了，现在已经养成了习惯，凡是操作文本文件必带encoding="utf-8"。

3.4 更安全的选择：json.JSONDecoder与众不同的容错能力

游戏测试里经常会遇到各种“不太规矩”的JSON，比如服务器日志里混了一堆调试信息、配置表导出的时候带了BOM头、或者干脆就是某个同事手欠多打了个逗号。直接用json.loads()去解析这些字符串，结果就是抛异常。

遇到这种情况，json.JSONDecoder()会给你多一些容错空间。它的raw_decode()方法可以在字符串开头解析出一个JSON值，剩余部分忽略不管：

from json import JSONDecoder decoder = JSONDecoder() data, end_index = decoder.raw_decode('{"code":0,"msg":"ok"} 后面还有一些垃圾信息') print(data) print(end_index)

这个能力在解析日志文件的时候特别有用——一行日志里前缀可能是时间戳、进程ID之类的文本，后面紧跟一个JSON对象，用raw_decode()可以轻松抽出来，不用先做字符串切片。不过要注意，raw_decode()同样要求JSON部分本身是合法的，逗号、单引号这种错误它一样不接受。

对于真正的容错需求，可以考虑demjson3之类的第三方库，但引入额外依赖之前要想清楚：游戏测试的脚本大多数时候跑在受控环境里，数据源格式相对固定，标准库够用就不要轻易加依赖，省得部署的时候出幺蛾子。

4. 游戏测试里的高频JSON处理场景实操

4.1 配置表校验：用Python写一个“找茬”脚本

游戏测试里最常见的一个需求就是校验配置表。通常策划会把配置导成JSON，格式可能是数组套对象，也可能是对象套对象。测试要确保里面没有低级错误。

举个具体例子，假设有一份道具配置items.json，结构是数组，每个元素是一个道具对象：

[ {"id": 1001, "name": "新手剑", "type": "weapon", "price": 100}, {"id": 1002, "name": "治疗药水", "type": "consumable", "price": 50}, {"id": 1002, "name": "重复ID道具", "type": "unknown", "price": -5} ]

肉眼一看就知道有问题，但配置多了之后肉眼根本看不过来。我通常会写一个校验脚本，把规则一步步加上去：

import json def load_items(path): with open(path, "r", encoding="utf-8") as f: return json.load(f) def validate_items(items): errors = [] seen_ids = set() valid_types = {"weapon", "consumable", "armor", "material"} for idx, item in enumerate(items): if not isinstance(item, dict): errors.append(f"第{idx}项不是对象格式") continue item_id = item.get("id") if item_id in seen_ids: errors.append(f"道具ID重复: {item_id}") seen_ids.add(item_id) item_type = item.get("type") if item_type not in valid_types: errors.append(f"道具ID {item_id} 的类型异常: {item_type}") price = item.get("price", 0) if not isinstance(price, (int, float)) or price < 0: errors.append(f"道具ID {item_id} 的价格异常: {price}") return errors if __name__ == "__main__": all_items = load_items("items.json") result = validate_items(all_items) if result: print("发现配置错误：") for err in result: print(" -", err) else: print("配置校验通过")

这个脚本的逻辑并不复杂，但它的价值在于：你可以把策划在配置里可能犯的所有错误类型都沉淀成规则，每次配置更新后跑一遍，就能在测试之前先把低级问题挡在门外。实际做的时候，规则只会比这个更细——比如掉落概率之和是不是1、技能ID是否在合法枚举范围内、引用的目标配置是否存在等等。

4.2 接口报文校验：从“能通”到“验得准”

接口测试是游戏测试工程师的重头戏。很多人用Python做接口测试，只会盯着HTTP状态码和返回里头的code字段，觉得只要code是0就万事大吉。但实际上，返回的数据结构、字段类型、字段取值范围，每一个地方都可能出错。

举个例子，一个领取每日奖励的接口，正常情况下返回：

{ "code": 0, "data": { "daily_reward": { "gold": 100, "item_list": [{"id": 3001, "count": 1}] } } }

但有一次我在测试中发现，服务器在某种边界条件下返回的data竟然是个空字符串，而不是一个对象。用json.loads()解析倒是没问题，但后续访问data["daily_reward"]就直接报TypeError: string indices must be integers。这种问题在Python脚本里会立刻暴露，但如果有人在代码里做了过度防御，反而可能让问题悄悄溜过去。

所以我写接口校验的时候，会重点检查这几个方面：

• 顶层字段完整性：code、msg、data是否都存在。
• data的类型：期望是对象还是数组？能不能为空？
• 关键字段的数值范围：金币是不是负数？数量是不是0？时间戳是不是合理区间？
• 嵌套结构的深度：某些异常情况下，服务器会不会只返回部分字段？

我会把校验逻辑封装成函数，每次接口调用后统一执行，这样既保证了准确性，又不会在业务代码里到处塞校验逻辑。

def check_daily_reward_response(resp_data): assert resp_data["code"] == 0, f"业务code错误: {resp_data['code']}" data = resp_data.get("data") assert isinstance(data, dict), f"data类型错误: {type(data)}" reward = data.get("daily_reward") assert isinstance(reward, dict), f"daily_reward缺失或类型错误: {reward}" gold = reward.get("gold", 0) assert isinstance(gold, int) and gold > 0, f"金币数值异常: {gold}"

这种写法非常直接，出错的时候报错信息一眼就能看出问题在哪。比起用一堆if判断然后打印日志，断言式校验在测试脚本里反而更高效。

4.3 日志数据提取：在千万行记录里捞“案发现场”

游戏服务端会滚动输出大量日志，里面经常混着JSON格式的关键信息。出问题的时候，测试要第一时间从日志里找到对应的记录，分析当时玩家的状态、请求参数、服务器返回。

有一次线上玩家反馈“充值到账延迟”，我处理的第一步就是去日志里捞那个玩家当天的充值记录。日志文件很大，直接打开搜索很慢，我写了个小脚本按关键词筛选：

import json def extract_json_from_line(line): try: start = line.index("{") decoder = JSONDecoder() obj, _ = decoder.raw_decode(line[start:]) return obj except Exception: return None keywords = ["player_id=10086", "recharge", "order"] with open("server.log", "r", encoding="utf-8") as f: for line in f: if any(kw in line for kw in keywords): obj = extract_json_from_line(line) if obj: print(json.dumps(obj, ensure_ascii=False, indent=2))

这个脚本的思路是：先用关键词粗筛，再用raw_decode()把行内嵌的JSON提取出来，最后用json.dumps格式化打印。实际处理海量日志的时候，效率、内存占用都是需要考量的点，但如果只是定位单个问题，这种逐行扫描的方式已经够用了。真遇到GB级别的日志，我一般会先把日志文件按时间范围切分，或者用grep命令先做一层筛选，再丢给Python脚本处理。

4.4 数据驱动测试：把测试用例从代码里“抽”出去

游戏测试的自动化用例，如果所有数据都硬编码在代码里，维护起来非常痛苦。策划改个数值，测试代码就得跟着改一遍，还容易引发连锁问题。更好的做法是把测试数据和业务逻辑分离，用JSON文件来存放用例数据。

[ { "case_id": "login_success", "request": { "username": "test001", "password": "123456" }, "expected": { "code": 0, "has_role": true } }, { "case_id": "login_wrong_password", "request": { "username": "test001", "password": "wrong" }, "expected": { "code": 1001 } } ]

测试脚本读取这个JSON文件，遍历执行每条用例：

import json def load_cases(path): with open(path, "r", encoding="utf-8") as f: return json.load(f) def run_case(case): url = "https://game-api.example.com/login" resp = client.post(url, json=case["request"]) resp_data = resp.json() for key, value in case["expected"].items(): assert resp_data.get(key) == value, f"{case['case_id']} 断言失败: {key}期望{value}实际{resp_data.get(key)}" for case in load_cases("login_cases.json"): run_case(case)

用这种数据驱动的方式，新增一条用例只需要往JSON文件里加一个对象，不需要动代码。但这里有个容易踩的坑——JSON文件里不能写Python风格的注释。很多人习惯了Python的#注释，往JSON文件里塞# 这里是登录成功用例，结果解析直接报错。一种绕过办法是在JSON里约定一个专门放备注的字段，比如"desc": "登录成功用例"，测试代码不去校验它就行。

5. 常见问题与排查技巧实录

5.1 中文变\uXXXX怎么办

最典型的表现是：json.dumps(data)之后，中文全变成了\u73a9\u5bb6这种。这是正常的，不是编码错误——JSON规范允许这种转义形式，多数解析器也能正确处理。问题是人类阅读排查的时候太费劲了。

解决方法就是加ensure_ascii=False参数。如果你已经生成了带\uXXXX的文件，想转回可读格式，可以用json.loads()把字符串解析回来，再重新dumps一次：

with open("bad.json", "r", encoding="utf-8") as f: data = json.load(f) with open("good.json", "w", encoding="utf-8") as f: json.dump(data, f, ensure_ascii=False, indent=2)

5.2 键值对顺序被打乱

Python 3.7之后，字典默认保持插入顺序，所以json.dumps()输出的JSON会按照你构造字典时的顺序来排列。但如果你是从文件里load进来的，然后再修改其中某个字段再dump出去，新加的字段会出现在最后，不会自动按字母序或某个逻辑顺序排列。

如果你希望输出时键的顺序是确定的，比如按拼音或按数字ID排，需要自己在代码里处理。可以构造一个collections.OrderedDict，或者更简单地，先取出所有键排个序再组装新字典。不过我个人觉得，在游戏测试的场景里，键的顺序对语义没有任何影响，只要解析方不依赖顺序就行，没必要过度纠结。

5.3 解析超大JSON文件时内存爆了

游戏测试中遇到超大JSON文件并不罕见，比如把全服玩家的信息导出成一个JSON，轻松几百MB。这时候如果直接用json.load()一次性读进来，内存很容易吃紧，甚至直接卡死。

这种情况下我建议评估一下你的真实需求：如果只是要查某几个特定字段，可以用流式解析的思路。标准库没有高效的流式JSON解析能力，但有一个ijson库可以做到。如果你只是要按大块切分处理，也可以先读文件，按括号层级切出一个个小的JSON片段再逐个解析。考虑到大多数游戏测试场景里，“超大JSON”也就是几百MB的规模，我通常的折中方案是——先确认到底需要哪些数据，如果只是统计类信息，用Python的逐行扫描也能解决；如果确实要做精细解析，那就上ijson或者干脆让开发侧导出更小的数据子集。

5.4 接口返回的是JSON数组但顶层不是对象

有些接口的返回值是数组，比如获取排行榜，直接返回：

[ {"rank": 1, "name": "playerA", "score": 9999}, {"rank": 2, "name": "playerB", "score": 8888} ]

新手拿到这种数据往往会愣一下，因为他习惯了解析成字典之后用键取值。实际上json.loads()解析数组后会得到Python的list，你只需要按列表的方式遍历就行：

data = json.loads(response_text) for item in data: print(item["rank"], item["name"], item["score"])

这种情况在接口测试里非常常见，不是什么异常数据，只要心里有数就行。

5.5 时间戳到底是不是毫秒

游戏服务器返回的时间戳，有的用秒级，有的用毫秒级，十位和十三位的区别。做断言的时候，如果拿当前时间直接去比对，很容易因为单位不一致导致误报。我的习惯是：拿到时间戳先判断位数，十位按秒处理，十三位除以1000转成秒，然后再跟当前时间做差值计算。同时还要考虑服务器时区问题，如果游戏是海外发行，时间戳直接涉及转换逻辑，测试脚本里也要一并处理。

5.6 嵌套深了之后取层级数据费劲

当JSON嵌套层级特别深的时候，比如data["activity"]["stages"][1]["rewards"]["items"][0]["count"]这种，写起来费劲，而且一旦某个中间层变成空值，整行代码直接崩。两种思路：一种是老老实实用get()逐层取，写个辅助函数；另一种是写一个通用函数支持点路径取值，比如get_value(data, "data.activity.stages[1].rewards.items[0].count")。第二种方式在自动化测试里会清爽不少，但实现的时候要注意索引的解析。我建议初学者先掌握第一种，把基础打牢，等真的写烦了再考虑封装工具函数。

6. 一些让JSON处理更顺畅的辅助工具与习惯

6.1 VS Code里装个JSON插件

做游戏测试，代码编辑器里离不开JSON相关插件。VS Code本身对JSON文件的支持不错，语法高亮、格式化、折叠都有。但我建议再装两个扩展：一个是JSON Tools，可以快速对选中的JSON做格式化和压缩；另一个是Prettier - Code formatter，写代码时顺手把JSON文件也统一格式化。我自己还喜欢用一个叫JSON to TS的扩展，不过这是在你需要把JSON转成TypeScript接口定义时才有用，游戏测试场景里用得少，主要是方便写前端工具脚本。

6.2 在线工具和本地开发的小习惯

在线JSON格式化、校验工具很多，我偶尔会用，但涉及敏感数据的JSON，我从来不丢到网上。数据安全这根弦什么时候都不能松。自己本地备一个随手能跑的格式化脚本，反而更稳妥：

import json import sys def format_json_file(src, dst=None): with open(src, "r", encoding="utf-8") as f: data = json.load(f) dst = dst or src with open(dst, "w", encoding="utf-8") as f: json.dump(data, f, ensure_ascii=False, indent=2) if __name__ == "__main__": format_json_file(sys.argv[1], sys.argv[2] if len(sys.argv) > 2 else None)

6.3 善用json.tool模块

命令行里临时想看一个JSON文件的结构，不用打开编辑器，直接：

python -m json.tool input.json output.json

这个命令会把input.json格式化后输出到output.json，如果原文件本身解析不了，它会在终端直接报错。我个人很喜欢这个命令，写脚本调试的时候临时格式化一下很方便，也不用额外写代码。

7. 在游戏测试这个方向上，JSON数据处理还得注意什么

游戏测试工程师学Python和数据处理，跟纯后端开发有个很大的不同——你不需要把每段代码都写得像生产环境那么健壮，但一定要能快速定位问题、快速验证假设。JSON数据处理也不例外。

我在带人的时候经常说一句话：“看JSON别只盯着值，要看结构变没变。”接口返回的JSON结构，在正常情况下应该保持稳定。如果你发现某一次返回的JSON字段比昨天少了两个，或者类型突然变了，这往往意味着服务端代码有改动，甚至可能是发错了版本。这种结构性变化，靠肉眼很难发现，所以我建议在自动化测试里加入“结构快照”对比的思路——定期把接口返回的JSON结构存成一份基准文件，每次跑用例的时候对比一下结构，一旦发现差异立刻报警。

另外，游戏测试处理JSON时会大量涉及数据一致性的问题。举例来说，客户端展示的货币数量、任务进度，和服务器返回的数据必须一致；服务器返回的奖励配置，和策划配置表里的数值必须一致。这些地方都需要你在脚本里做联合校验，而不是只断言单个字段的值对不对。

有一点必须强调：JSON数据本身没有类型约束，但它承载的业务语义往往有严格的类型要求。比如player_id如果设计成字符串，那不管什么情况下都不能变成整数，否则下游系统拼接、索引、缓存可能全部乱套。测试的时候要有意识地造一些“类型边界”的用例，比如传一个数字型ID、传一个带小数点的经验值、传一个空字符串作为名称，看看服务端能不能正确处理。这些用例不在策划配置里，但你写了，就能帮团队提前挡掉很多脏数据问题。

还有一件事，如果是做客户端自动化，经常要读取本地存档或配置文件，这些文件很多也是JSON格式。这时候要注意：不要假设配置文件的键一定存在。游戏版本迭代过程中，旧存档可能缺少新版本才有的字段。你的解析代码必须要能容忍这些缺失，否则老玩家一更新就崩溃。通常的做法是用get()加默认值，或者解析后统一做一次字段补全。

8. 折腾几次之后，我养成的几个JSON处理习惯

说到底，JSON数据处理不是一门“学完就完事”的知识，而是在反复实践中慢慢沉淀出的一套直觉和习惯。我自己折腾了几年，最后养成这么几个习惯：

第一，所有涉及JSON的读写，统一走Python的json模块，不用正则硬抠。看起来正则也能匹配出某个字段，但只要嵌套结构稍微复杂一点，正则就会变得极其脆弱。用json.loads()先解析成Python对象，再用字典和列表操作去访问，逻辑又清晰又稳。

第二，格式化输出时，ensure_ascii=False和indent=2是默认配置。除非明确要压缩体积，否则我都会把它们加上。这俩参数看着平平无奇，但能让你在调试和排查时省下大量眼睛的力气。

第三，校验JSON时，先校验结构，再校验值。我会先写一组函数确保对象、数组、嵌套层级、字段类型都是预期内的，然后再去检查数值范围、逻辑关系。顺序反了的话，很可能一个键值错误触发一串异常，排查起来反而更慢。

第四，处理完一批JSON数据，随手落一份日志或输出文件。游戏测试经常要对着结果复盘——这条数据怎么改的、中间经过了哪些转换、最终结果是什么样。把中间产物留下来，出了问题时能倒查，不会翻来覆去找不到线索。

这些习惯不一定适合所有人，但对我来说，它们实实在在地减少了排查问题的时间。数据处理这活儿，做了十年的老手和刚入门的新手，差别未必在语法上，更多的就是在这些细碎的习惯里。

如果你也在游戏测试这条路上慢慢磨Python，建议你现在就打开一个真实的JSON文件——不管是配置表、接口返回还是日志记录——亲手写一遍加载、解析、校验、转换、落盘的完整流程。走完这一圈，你对JSON数据处理的体感会比看十篇文章都来得实在。