这玩意不得不套了，需要的属性太多（滚动，滚动条等），这玩意要是不提出来，放在children，那简直就是毒瘤了
typedef HimalayaItemBuilder = List<Widget> Function(HimalayaItemInfo item); class HimalayaLeftNavigation extends StatelessWidget { .......... Widget _buildItemListBg({HimalayaItemBuilder itemBuilder}) { return Expanded( child: Scrollbar( child: SingleChildScrollView( child: Column( crossAxisAlignment: CrossAxisAlignment.start, children: data.leftItemList.map((e) { return Column( crossAxisAlignment: CrossAxisAlignment.start, children: itemBuilder(e), ); }).toList(), ), ), ), ); } }第二层
这里面必须需要第一层遍历的具体数据源，所以必须增加一个输入参数
这里就是常规提取，需要注意的就是传入的数据源
typedef HimalayaRxSubBuilder = Widget Function(Rx<HimalayaSubItemInfo> item); class HimalayaLeftNavigation extends StatelessWidget { .......... Widget _buildSubItemListBg({HimalayaItemInfo data, HimalayaRxSubBuilder subBuilder}){ return Column( children: data.subItemList.map((e) { return subBuilder(e); }).toList(), ); } } 总结经过上面的一通操作，业务Widget立马变的清爽N倍
大家在写Flutter的时候，应该能明显的感觉到，写页面拥有高度的自由，样式、页面结构及其逻辑全都能耦合在一起；所以在实际开发中，更要注意自己代码规范。
假设一种情况：你开发完一个模块，过了几月之后，需求调整，你要去改这个模块，看到几千行的套娃页面代码，然后一边改一边骂骂咧咧，然后喷是哪个睿智的人写的，最后打开文件的git注释（annotate）记录，如果上面写满了你的名字，那岂不是很尴尬。。。
题外话说一点题外话
实际上写html也是无限套娃，不同的是，它从根本上做到的样式结构分离，控件的细节描述，全部交给了css去做，所以页面整体看上去还是满清爽的：
但是有一点让我很蛋筒，写小程序的时候，查看具体控件的描述样式，需要跨文件去找
uniapp则是直接把这些东西放在一个文件里（19年写的时候是这样的，不知道现在有没有改），算是一种改善，查找起来方便，但是单个文件代码量有点爆炸
样式因为是交给css去处理，层级描述也放在css中，有时候看代码看的有点懵逼（是我太菜了）
Flutter直接从根本上样式结构不分离，结构上直接从上往上下一套到底
优点：修改样式简单（方便定位）；结构清晰（从上往下看就行了）
缺点：代码阅读，观感爆炸；不做模块划分，后期代码维护困难
所以，哪里有十全十美的框架，总是有舍有得。。。
新的事物发展，必然会迎来相应的阻力
这里假设一种场景：
你已经写了俩三年Flutter了，各种控件，框架玩的牛的飞起
然后，你听说：又来了一种神奇的，跨时代的前端框架，甚至能无缝调用所有平台的底层硬件api，omg，反正就是各种6
然后你看到，关于这种跨时代框架的文章，在各个技术论坛中，疯狂涌现
此时，你心中会不会有丝丝异样，心想：杂家，这几年Flutter白写了？又得去学这个新框架了？我踏马岂不是又变成萌新了！又要天天去群里抱大佬大腿了！
然后你看到那一片片热点文章，文章下满是捧上天的评论，，，
此时，你的心中会不会有丝波澜，想当一当这技术界的清醒者，情不自禁吟诵：众人皆醉我独醒.....
然后，拿起键盘，化身一个大喷子，以一敌百，不落下风
一瞬间，让你觉得：这个论坛，现在叫lbw论坛！我就是这论坛的王！
角色互换
其中，对于很多言论，我们没必要在意，角色互换，说不定，对方此刻的行为，就是我们自己以后可能会做的事。