flask的request.get_json()返回none的首要原因是请求头content-type非application/json；需显式设置该header，空体、格式错误或编码问题也会导致失败。
Flask 默认不解析非 application/json 请求体，request.get_json() 对表单、空体或错误 header 会直接返回 None —— 这是嵌套 JSON 解析失败的首要原因。
为什么 request.get_json() 总是 None
这不是代码写错了，而是请求没发对。Flask 只在 Content-Type: application/json 时触发 JSON 解析；其他类型（比如 application/x-www-form-urlencoded 或没设 header）一律跳过，返回 None。
- 前端用
fetch或axios时，必须显式设置headers: {'content-type': 'application/json'} - 用
curl测试时，漏掉-H "content-type: application/json"就会失败 - 浏览器地址栏直输 URL 或表单提交，默认是
application/x-www-form-urlencoded，get_json()必然为None - 空请求体、JSON 格式错误（如尾逗号、单引号）、编码非 UTF-8 也会导致
None
如何安全读取并验证嵌套结构
别依赖单一入口。先尝试 get_json()，失败后按需 fallback，但要注意：form 不支持嵌套，仅作临时调试用。
- 始终检查
data is None，而不是直接data['user']['profile'] - 用
request.is_json做快速判断，比get_json()多一次解析开销但更清晰 - 对嵌套字段做存在性校验：
data.get('user', {}).get('profile', {})比链式访问安全 - 若需强约束，立刻用
jsonschema或marshmallow验证，别等到业务逻辑里才报错
用 marshmallow 处理字段名与键名不一致
JSON 键是 user_profile，Python 字段想叫 profile？不能靠重命名变量，必须用 data_key 显式映射。
-
profile = fields.Nested(UserProfileSchema, data_key="user_profile")—— 输入时认user_profile，内部存为profile - 嵌套列表必须用
fields.List(fields.Nested(SubSchema))，不是fields.Nested(SubSchema, many=True) -
data_key影响序列化输出：默认仍按data_key输出键名；如要保持 Python 字段名输出，加dump_only=True或改用attribute - 错误信息路径是嵌套的：
ValidationError的.normalized_messages()返回带user.profile.age这种路径的字典，别只看顶层 key
深层嵌套访问时容易忽略的边界
拿到解析后的 dict，直接 data['a']['b']['c'] 是高危操作。哪怕 schema 验证通过，运行时仍可能因数据缺失崩掉。
- 用封装函数
safe_get(data, 'user', 'profile', 'address', 'city')替代硬访问 - 列表索引必须校验：
data['items'][0]前先确认len(data.get('items', [])) > 0 - 混合类型字段（如
"tags": ["a"]或"tags": "a"）需用isinstance(value, list)判断后再处理 - 递归解析时限制深度（如
max_depth=10），防止恶意超深嵌套耗尽栈空间
最麻烦的不是怎么写解析逻辑，而是前端发错格式、字段名拼错、或嵌套层级比预期多一层——这些都不会报语法错误，只会让 data 突然变 None 或某个子字段消失。每次上线前用 curl 加完整 header 和 body 验证一遍，比写十个单元测试还管用。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
