本来不想说的，在各种场景下频繁遇到这个问题，还是发出来讨论下。
由于调试与表单验证相关的bug，阅读了 uni-forms, uni-form和其它输入组件的代码。uni-forms现有的验证机制，需要 uni-forms, uni-form-item, 输入组件例如 uni-easy-input 三者相互配合才能工作，看似完美，但是这导致 uni-forms只能较好支持自身的输入组件，对用户自定义组件的支持很不友好。要配合 uni-forms的验证机制，自定义组件只是实现 v-model 是不够的，还需要 调用 getForm 获取 form, formItem对象，并赋值 rename才能保证验证机制工作。
为什么 uni-forms 的验证机制不能很好支持 仅实现 v-model的自定义组件？ 如果组件实现 v-model，uni-forms监听数据执行验证，这样似乎也行啊， 不清楚为什么 uni-forms的验证机制做得如此复杂，导致自定义组件不能很好支持验证，而 uni-forms自带的输入组件有仅有 uni-easy-input, uni-data-checkbox, uni-data-picker，导致稍微复杂点的业务逻辑都很难用表单实现，我认为这成为 uni-ui 表单的一个瓶颈。
总结下， uni-forms, uni-form-item和uni-ui自带的输入组件耦合度过高，导致 uni-forms对用户自定义组件支持度很差，然后因为 uni-ui自带输入组件又少，导致表单能够支持的输入方式有限，限制了业务实现。
2 个回复
3***@qq.com
可以直接说，DCloud的技术开发要么是需求指向有问题，要就是技术构架取向有问题，耦合度过高的问题在很多模块中都存在，不知道是不是增加用户粘性的欲望太强，模块的复杂性让用户能进行的修改非常有限，非常限制用户的自定义开发，在为用户提供一些便利性的同时，又带来了一些限制，反正不太理解为什么要这样做。
择善固执 (作者) - 择善固执，日拱一卒
一个好的框架需要有高水平的设计，不缺钱，有牛人，牛人愿意全身心投入，这些都是可遇不可求的，所以能用就好了，不再期待。
将就一下。