序列化时校验器运行是因为required、allow_none等参数影响dump行为；load_only字段只参与反序列化，dump时跳过；嵌套字段需显式设load_only/dump_only；post_load/post_dump仅在对应操作成功后触发。
序列化时为什么校验器还在跑？
因为 Schema.load() 和 Schema.dump() 默认共用同一套字段定义，而字段的 validate 参数只在反序列化（load）时生效，但如果你误用了 required=True 或 allow_none=False 这类约束，dump 时也可能抛错——尤其是字段值为 None 且没显式允许时。
常见错误现象：ValidationError: {'field_name': ['Field may not be null.']} 出现在调用 schema.dump(data) 时。
- 检查字段是否写了
allow_none=False（默认就是 False），dump 前值为None就会触发校验失败 - 把校验逻辑全塞进
validate=是安全的，它只在load()中执行；但required、missing、allow_none这些参数会影响 dump 行为 - 如果字段仅用于序列化（比如只读字段），用
dump_only=True，它会自动忽略required和validate
怎么让一个字段只校验不序列化？
典型场景：前端传密码字段做校验，但绝不返回给前端。不能靠删掉 key，得从 Schema 设计上隔离。
- 用
load_only=True标记该字段，它只参与load()，dump 时直接跳过 - 别在
load_only字段上设dump_default或dumps相关钩子，它们无效 - 如果需要对
load_only字段做复杂校验（比如密码强度），写在@validates('password')里，不会污染 dump 流程
示例：password = fields.Str(load_only=True, validate=Length(min=8))
Secure Python Code Sandbox
下载
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
立即学习“Python免费学习笔记（深入）”；
嵌套 Schema 怎么控制内外层校验/序列化方向？
嵌套字段（fields.Nested）默认继承外层行为，但容易漏掉方向控制，导致子 Schema 的 load_only 字段在父级 dump 时意外消失，或校验被跳过。
- 嵌套字段本身也要显式声明
load_only或dump_only，不能只依赖子 Schema 的设置 -
fields.Nested(UserSchema, load_only=True)比在UserSchema里设load_only=True更可靠——前者控制调用点，后者只影响该 Schema 实例 - 如果嵌套字段是列表（
fields.List(Nested(...))），每个元素仍受相同规则约束，别以为加了many=True就能绕过方向控制
自定义字段方法（post_load/post_dump）何时触发？
这两个钩子常被当成“万能补丁”，但它们的触发时机和上下文很关键：不是所有数据流都会经过它们，且错误处理方式不同。
-
@post_load只在load()成功后执行，接收的是已校验的字典，返回值成为最终结果；如果它抛异常，会被包装成ValidationError -
@post_dump只在dump()成功后执行，接收的是待序列化的原始数据（非字典！可能是对象），返回值替换原输出；但它不参与校验，也不影响字段级约束 - 别在
@post_dump里改字段值类型来“绕过”校验——比如把None改成空字符串，这会让allow_none=False失效，但实际只是掩盖问题
容易被忽略的一点：如果 Schema 有 unknown=EXCLUDE，@post_load 接收到的数据已经过滤过未知字段，别指望它处理原始输入。
