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 没配全，等于给验证开了后门，而且这后门还藏在层层缩进和引用里，不容易一眼揪出来。
