fastjsonschema.compile() 仅在重复校验同一schema时加速，因编译生成纯python函数跳过每次解析；单次校验或循环内调用反而更慢，且编译期报错会阻塞服务启动。
fastjsonschema.compile() 为什么比 validate() 慢？
编译本身不加速，反而多花一次解析和生成 Python 函数的开销。只有反复校验同一份 schema 时，compile() 才值得——它把校验逻辑变成纯 Python 函数，跳过每次 parse schema 的步骤。
常见错误现象：compile() 被放在循环里调用，结果比直接用 validate() 还慢；或者只校验一次数据，却坚持先 compile。
- 使用场景：HTTP API 中，schema 固定、单次请求需校验多个数据（如批量上传），或长时运行服务中持续接收同类结构数据
- 参数差异：
compile()返回一个 callable，接收data；validate()直接接收schema和data - 性能影响：首次 compile 可能耗时几十毫秒（尤其带复杂
if/then/else或深度anyOf），但后续调用可快 3–10 倍
如何避免 compile 失败导致服务启动卡住？
fastjsonschema.compile() 在 schema 有语法错误或不支持特性时，会抛出 JsonSchemaDefinitionException，不是运行时报错，而是编译期就崩——如果写在模块顶层或 Flask/Django 启动时，整个服务起不来。
- 务必把
compile()放在 lazy 初始化位置，比如第一次请求时缓存，或用functools.lru_cache包一层 - 不要依赖
try/except在 compile 处理业务逻辑错误；它只该捕获 schema 定义问题，不是数据格式问题 - 兼容性注意：fastjsonschema 对
$ref的本地文件引用（如file://）默认禁用，开启需传handlers={"file": ...}，否则 compile 直接报RefResolutionError
编译后的 validator 能否复用到不同线程或进程？
可以，编译结果是纯函数，无状态、无可变闭包，线程安全。但不能跨进程直接 pickle 传递——因为生成的函数含动态代码对象，在另一进程 unpickle 会失败。
立即学习“Python免费学习笔记（深入）”；
- 多线程：放心全局复用同一个 compiled validator
- 多进程：每个 worker 启动时各自
compile()一次，别试图从主进程传过去 - 性能提示：若用 Gunicorn + preload，确保 compile 发生在 worker 初始化阶段（如
post_fork钩子），而非模块导入时（可能被主进程执行，然后 fork 后失效）
为什么加了 use_default=True 编译后反而更慢？
这个参数会让编译器插入默认值填充逻辑，生成的校验函数体积更大、分支更多。实测在简单 schema 上影响不大，但在嵌套深、default 字段多的场景，函数字节码膨胀明显，Python 解释器执行也更慢。
- 真实使用场景：仅当业务明确需要“缺失字段自动补 default”且校验后立刻用该数据时才开；否则建议由上层逻辑处理默认值
- 容易踩的坑：误以为
use_default=True能让校验更“宽松”，其实它不改变 required 检查，只是补值——补完仍可能因类型不符而报错 - 替代做法：用
dict.setdefault()或 Pydantic 的model_construct()做默认填充，把校验和补值解耦
pattern）、没缓存的远程 $ref，或者把 compile 当成万能加速开关塞进热路径。盯住你的 profile 数据，而不是文档里的“快 10 倍”。 
