Formily 表单校验中 required 字段的陷阱与最佳实践

问题背景

在 Formily 表单开发中，required 字段是控制表单必填校验的核心属性。然而，开发者在使用过程中可能会遇到一个隐蔽的问题：当在 Schema 层和 Validator 层同时使用 required 属性时，两者对 undefined 值的处理行为不一致，这可能导致 UI 展示与校验逻辑不匹配的问题。

问题现象

当我们在 Schema 层设置 required: undefined 时：

• UI 层不会显示必填标识（红色星号）
• 校验层也不会执行必填校验

而在 Validator 层设置 required: undefined 时：

• UI 层同样不会显示必填标识
• 但校验层却会执行必填校验

这种不一致性容易导致开发者误判表单行为，特别是在复杂表单场景下。

技术原理分析

Schema 层的处理机制

Formily 在 Schema 层处理 required 属性时，会通过 setValidatorRule 函数自动补全 validator 规则。关键点在于：

1. 系统会先对 required 值进行 isValid(value) 校验
2. 如果值为 undefined，isValid 返回 false，直接跳过规则补全
3. 最终 validator 中不会添加 required 规则
4. 结果表现为 UI 和校验都按非必填处理

Validator 层的处理机制

Validator 层对 required 的处理则完全不同：

1. 只要存在 required 属性（即使是 undefined）
2. 校验规则实现中，只有明确设置为 false 才会跳过必填校验
3. 其他情况（包括 undefined）都会执行必填校验
4. 但 UI 层只识别 true 值才会显示必填标识

问题根源

这种不一致性源于两套校验机制的设计差异：

1. Schema 层采用了更严格的类型检查，undefined 被视为无效值
2. Validator 层则采用了更宽松的检查，任何非 false 值都会触发必填校验
3. UI 层只响应 true/false 的明确值

解决方案与最佳实践

临时解决方案

开发者可以采取以下方式避免问题：

1. 统一使用 true/false 明确值，避免使用 undefined
2. 优先使用 Schema 层的 required 配置
3. 如需使用 Validator 层，确保 required 值明确

长期优化建议

从框架设计角度，建议做以下优化：

1. 统一 Schema 和 Validator 层对 required 的处理逻辑
2. 明确 required 只接受 boolean 类型
3. 在类型定义和文档中明确说明 required 的使用规范

实际开发建议

在实际项目开发中，推荐：

1. 优先使用 Schema 层配置必填规则
2. 如需自定义校验，使用完整的 validator 函数而非简写
3. 避免混合使用 Schema 和 Validator 的 required 配置
4. 对必填字段始终使用明确的 true/false 值

总结

Formily 作为强大的表单解决方案，在处理复杂场景时仍有一些细节需要注意。理解 required 字段在不同层的处理差异，有助于开发者构建更可靠的表单逻辑。框架未来的优化方向应该是统一校验行为，减少这类隐晦的陷阱。