json schema 中数组验证必须配置 items 字段,仅 type: "array" 无法约束元素类型;items 可设固定类型、anyof 联合类型,并配合 minitems/maxitems 控制长度;ajv 需启用 stricttypes 并显式声明 nullable;yaml 转换时须确保 items 正确缩进;嵌套数组需逐层独立定义 items,推荐用 $ref 复用。
json schema 里怎么写数组格式的验证规则
数组不是加个 type: "array" 就完事了,必须配 items 才能真正约束内容格式。否则校验器只认“是数组”,不管里面是字符串、对象还是混着来的。
常见错误现象:["a", 123, {"id": 4}] 过了验证,但业务上只允许全是字符串——这就是漏掉 items 导致的。
-
items是必填项,只要你想验证数组元素的内容类型 - 如果数组元素类型固定(比如全是对象),直接写
items: { "type": "object", "properties": { ... } } - 如果元素类型不统一(如字符串或数字二选一),用
items: { "anyOf": [{ "type": "string" }, { "type": "number" }] } - 想限制数组长度?补上
minItems和maxItems,别指望items自带长度控制
用 Ajv 验证含数组的 JSON 时为什么总跳过校验
Ajv 默认不开启 strictTypes,遇到字段缺失或类型松散就静默放过。数组里混进 null 或 undefined,没显式配 "nullable": true 就可能被忽略。
使用场景:后端接收前端传来的标签列表 tags: ["a", "b"],但前端偶尔发 tags: ["a", null],Ajv 却没报错。
- 初始化 Ajv 实例时加上
{ strictTypes: true },强制类型匹配 - 数组元素若允许
null,在items里明确写"type": ["string", "null"],别依赖默认行为 - 检查是否误用了
additionalProperties: false在父级对象上——它不影响数组内部校验,但容易让人误以为“全关严了” - 调试时加
console.log(ajv.errorsText()),别只看validate()返回布尔值
YAML 配置转 JSON Schema 后数组规则失效了
很多结构化配置工具(比如 Swagger / OpenAPI)用 YAML 描述 schema,但 YAML 的缩进和破折号(-)容易让 items 层级错位,生成的 JSON Schema 里 items 可能挂在错的对象上,甚至整个字段消失。
典型错误配置:
DMap GL地图JSAPI(dmapgl)开发指南。用于编写、审查、调试 DMap 地图 API 代码,涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
tags: type: array - type: string # ❌ 这行缩进错,YAML 解析器会把它当数组元素,不是 items 定义
正确写法:
tags:
type: array
items: # ✅ 必须顶格对齐到 type 下,且用 items 字段名
type: string
- 所有
items必须作为 key 出现,不能靠缩进模拟数组字面量 - 用
yq或在线 YAML-to-JSON 工具实时验证生成结果,重点看items是否出现在最终 JSON 的对应位置 - 如果用 OpenAPI 3.0,
schema.items是强制字段,缺了会导致 spec 校验失败,而不仅是运行时无效
嵌套数组(如数组里套对象再套数组)怎么一层层写验证
嵌套越深,items 嵌套也越深,但每层都必须独立定义 items,不能“继承”外层类型。最容易被忽略的是中间对象里的数组字段没配 items,导致只校验了对象结构,放过了其内部数组的脏数据。
示例场景:用户提交订单,其中 items 是商品列表,每个商品有 options 数组,每个 option 是 {"name": "颜色", "value": "红"}。
- 外层数组(
items)的items是商品对象 schema - 商品对象里
options字段还得单独配"type": "array"+"items",不能省 - 避免重复定义:把深层 schema 抽成
$ref,比如"options": { "$ref": "#/components/schemas/OptionList" } - 性能影响:每多一层
items嵌套,Ajv 构建 validator 时编译时间略增,但运行时开销几乎不变;真正拖慢的是深层循环校验 + 大量if分支,不是嵌套本身
复杂点从来不在“能不能写出来”,而在“改一处,漏三处”。数组的 items 没配全,等于给验证开了后门,而且这后门还藏在层层缩进和引用里,不容易一眼揪出来。










