lessonPackageInfo对象的结构如下：//一个对象，用于配置title列和对应的字段titlecolumn//type指定了value的类型，现在组件内部设置可能会显示哪些类型的values//对于service来说，返回10来显示是否需要提供number一个map_data来映射//跨列的column属性设置//需要自定义显示内容到provideslotlessonPackageInfo:{orderType:{type:'option',desc:'classpackagecategory',map_data:{1:'firstorder',2:'Renewal',5:'免费课程'}},combo:{type:'text',desc:'Packagename'},presentedHours:{type:'text',desc:'Giveawayhours',slot:true},price:{type:'text',desc:'StandardPrice'},gifts:{type:'text',desc:'Gifts',column:3,slot:true},}道具不够直观，配置items怎么不完全数据驱动呢？为什么组件的配置项不好？这种需求是非常固定的。组件的输入，也就是props，应该最小化，组件的功能应该最大化。尽量为props提供默认值，以提高团队的开发效率。为什么它不是完全数据驱动的？该组件并非完全由数据驱动。如果需要自定义显示栏目，需要自己写一个模板。如果需要自定义很多列，就需要写很多模板代码。如果要再次提取，只能重新打包组件。如果您不提取它，模板代码可能会扩展。你可能经常看到每行500行的模板？臃肿的模板代码导致组件维护困难，需要在模板和js代码之间来回切换。此外，要添加一列自定义数据，至少需要修改两个地方。为什么需要完全数据驱动？虽然有扩展组件的槽，但是我们在写业务组件的时候要少用，而要尽量使用数据驱动的模板。因为数据是js代码，当组件代码展开时，很容易将js代码提取到一个单独的文件中，但是如果要提取槽代码，只能将组件重新打包。三大前端框架的设计理念都是数据驱动模板，这是区别于jQuery的重要特征，也是我们封装业务组件时首先遵循的原则。看了组件使用的问题，再看组件的代码：{{field.map_data[data[key]]}}{{field.map_data[data[key]]}}{{field.map_data[data[键]]}}{{field.map_data[data[key]]}}