本文探讨前后端共用校验规则的最佳实践，核心在于确立单一事实来源（SSOT）。推荐三种方案：基于后端 Pydantic 生成 OpenAPI/JSON Schema 供前端使用；配置驱动表单共享 JSON Schema；或前端 Zod 定义后转 JSON Schema 给后端。建议将校验分为可共享基础规则与后端权威业务规则两层。对于 django-ninja + Pydantic 项目，首选方案一，实现接口定义、运行时校验、文档与前端类型四合一，确保后端为最终权威。
要'前后端共用一套校验规则'，核心是选一个单一事实来源（Single Source of Truth），然后两端都从它生成/执行校验。最成熟、落地成本最低的路线通常是 JSON Schema / OpenAPI 驱动。
下面给你 3 套常用方案（从最推荐到特定场景），你可以按项目形态选。
单一事实来源：后端的 Pydantic Schema（django-ninja / FastAPI）
你用 django-ninja 的 Schema/ModelSchema 定义请求体约束（必填、类型、范围、regex、枚举、嵌套结构），并且保证接口请求都会经过它校验。
典型链路：
Pydantic Schema (后端) ← 单一事实来源 ↓ 自动生成 OpenAPI / JSON Schema ↓ 前端：生成 TypeScript 类型 + AJV 校验器
优点
前端落地要点
ajv 校验 JSON Schema（支持条件、oneOf、pattern、min/max 等）注意：后端的自定义校验（跨字段/查库）很难完全自动落到前端，这类规则建议拆成'基础规则可共享 + 业务规则后端权威'。
单一事实来源：JSON Schema 文件/数据库配置
适合：
做法：
优点
缺点
if/then/else 覆盖一部分）单一事实来源：前端 Zod（或 Yup）
适合：
做法：
jsonschema 校验优点
缺点
无论用哪种方案，都建议把校验分层：
前端可以做'弱提示'，但最终以服务端为准。
如果你们表单不是高度动态配置，我建议直接走 方案 1：
Schema/ModelSchema 定义请求体这样你能做到：
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
解析常见 curl 参数并生成 fetch、axios、PHP curl 或 Python requests 示例代码。 在线工具，curl 转代码在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML 转 Markdown 互为补充。 在线工具，Markdown 转 HTML在线工具，online
将 HTML 片段转为 GitHub Flavored Markdown，支持标题、列表、链接、代码块与表格等；浏览器内处理，可链接预填。 在线工具，HTML 转 Markdown在线工具，online
通过删除不必要的空白来缩小和压缩JSON。 在线工具，JSON 压缩在线工具，online