不能直接生成完整、可上线的数据校验逻辑——它能产出基础结构，但关键校验规则（如正则、范围、嵌套字段必填）必须人工补全，生成结果常漏掉 required 声明、format 约束、深层 properties 嵌套定义，且默认不处理错误提示聚合或异步校验场景。
CodeGeeX 能不能直接生成带 schema 校验的 JS 逻辑？
不能直接生成完整、可上线的数据校验逻辑——它能产出基础结构，但关键校验规则（如正则、范围、嵌套字段必填）必须人工补全。生成结果常漏掉 required 字段声明、format 类型约束、深层 properties 嵌套定义，且默认不处理错误提示聚合或异步校验场景。
常见错误现象：CodeGeeX 输出的 validateUserInput 函数只做 typeof 判断，对手机号没用 /^1[3-9]\d{9}$/，对金额没做 Number.isFinite + 范围检查，对对象字段缺失也不抛统一错误。
- 使用场景：适合快速搭出校验函数骨架，比如表单提交前调用
validate()返回布尔值 - 参数差异：若提示词写“校验用户注册数据”，AI 可能只校验顶层字段；加一句“包含 address.city 和 payment.cardNo 的嵌套校验”，才会生成带
data.address?.city访问链的代码 - 性能影响：生成的校验逻辑若用
JSON.stringify深比较或遍历所有 key，会拖慢大对象校验；应手动替换为for...in+hasOwnProperty或Object.keys
Red Hat YAML 插件对 JSON Schema 校验的支持边界
它只在校验 .yaml 文件时生效，且依赖 yaml.schemas 配置中的 URL 或本地路径映射。如果你在 .js 里写 const schema = { type: "object", properties: { ... } }，插件完全不识别——它不解析 JS 内部变量，只扫描文件后缀 + $schema 字段或配置绑定。
常见错误现象：YAML 文件里写了 $schema: "./user.schema.json"，但 VSCode 仍报“Unknown property”，说明 settings.json 中没把该路径映射到对应 schema URL，或本地 user.schema.json 缺少 $id 字段导致引用失效。
- 使用场景：适合 Kubernetes、CI 配置等静态 YAML 文件的字段级提示和报错，不适用于运行时动态加载的 schema
- 配置要点：必须用通配符路径匹配文件（如
"**/schemas/*.yaml"），不能只写"*.yaml"；远程 schema URL 必须可访问，否则补全和校验全部失效 - 兼容性影响：若 schema 使用
unevaluatedProperties: false，老版本插件（yaml-language-server 版本 ≥ 1.5.0
ESLint 的 complexity 规则怎么配合校验逻辑开发？
它不校验业务逻辑对错，但能卡住校验函数本身的可维护性。一个含 20 个 if/else if 分支的 validateOrder 函数，圈复杂度轻松破 20，eslint 会标红并阻止保存——这恰恰说明你该把校验拆成 validatePayment()、validateShipping() 等独立单元。
常见错误现象：开发者为绕过 complexity 报错，把校验逻辑改成 switch + 大量 case，看似降低分支数，实则掩盖了职责混杂问题；或用 eval 动态拼接校验表达式，触发 no-eval 规则。
- 配置建议：
"complexity": ["error", { "max": 6 }]—— 校验函数理应简单，超过 6 个控制流节点，大概率需要拆分 - 例外处理：对自动生成的 schema 校验代码（如通过
ajv编译器产出），可在文件顶部加// eslint-disable-next-line complexity，避免误伤 - 联动效果：配合
no-unused-vars和no-shadow，能提前发现校验函数里未使用的中间变量或作用域污染
为什么别指望 CodeMetrics 显示校验函数的“校验覆盖率”？
CodeMetrics 只算圈复杂度（C）、维护性指数（M）、逻辑行数（L），它不知道哪一行是校验逻辑、哪一行是错误组装、哪一行是日志输出。一个 C=8 的 validate 函数，可能有 5 行在构造错误消息，只有 3 行真正在做字段检查——但插件不会区分。
容易被忽略的地方：校验逻辑的质量核心在于“是否覆盖所有边界条件”，而不是“函数有多长”。CodeMetrics 显示 L=12，不代表这 12 行都有效；它甚至无法识别 if (x) { return true; } else { return false; } 这种冗余写法。
- 真实需求：要测校验覆盖率，得用 Jest +
istanbul运行测试用例，看validate()的分支是否全被触发 - 替代方案：用
ESLint的no-else-return、no-unreachable等规则，先扫掉明显无效的校验分支 - 工具定位：把
CodeMetrics当作“函数体积预警器”，不是“校验质量检测仪”——它提醒你该看代码了，但不告诉你哪里漏了校验
