上面关于页面层的这些问题，如果多人协同开发一个大型项目，代码不规范的话，大概率都是会遇到的（改别人写的模块...）；后期改需求，真的是一种折磨，有种码海找针的感觉。
如果改你自己写的模块，那可能还会好点，毕竟你还有点印象，整个模块的大概思路，还知道怎么改。如果是改别人写的模块，你就需要在大量widget海中，去揣摩别人写这些widget的意图，结构一下子也不能理清，十分痛苦，有可能边改边骂骂咧咧的。。。
说明
代码已经发布到Github上，web端也已经部署好了，因为使用的CanvasKit模式打包的，首次加载可能比较慢，多等一会，因为Web端部署在Github上，访问的话，要确保你的网络能访问Github。
来对比下仿制的效果吧，有个六七成相似，很多Icon和图片实在找不到相似，，，这里demo只提供一个样式演示，功能别想了，这不是一朝一夕，一个人能搞出的。。。
照片都是从喜马拉雅web端上搞下来的，数据一直在变，相应栏目的数据有对不上，但是整体样式大致还是差不多。
其中Banner模块是区别最大的一块，用的三方库只能支持搞成这样，各位靓仔将就着看看吧。
上面俩组图片，细节方面对比基本惨不忍睹，但是整体架构上还是比较相似。
建议各位彦祖，下载下window安装包，安装体验下；MacOS的于晏们，你们可以看看web展示效果。
咱们马上来看看怎么搞规范代码吧！复杂的模块，让你的代码也能高度可维护！
结合上面的业务View和一切皆Widget的思路，我们可以得出一个结论：搞业务Widget，然后再进行组合！
当然，咱们在这里得出了一个不是结论的结论，一般来说，这种操作是咱们基本素养，但是具体的操作细节上，还是有很多需要注意的：
上面咱们一通分析猛如虎后，得出一个结论：搞业务Widget！
关于业务Widget的封装细节，这里说明下：
别喷套娃了，外观模式的思想稍稍这么一用，套娃直接GG
设计模式，yyds！
一般来说，一个页面整体基本上是横向（Row）或者纵向（Column）的结构
咱们仿造的喜马拉雅模块也是属于纵向结构：上下俩大模块
主模块的很多主体细节，是完全可以封装起来的，新建一个（模块名_function）文件
///喜马拉雅整体外层布局设置WidgethimalayaBuildBg({requiredList
几个要点
先来看看第一种情况，最常见的情况，children的widget，从上到下排列下来，非列表类数据
大家在写Flutter的时候，应该能明显的感觉到，写页面拥有高度的自由，样式、页面结构及其逻辑全都能耦合在一起。
既然我们还达不到，无招胜有招的水平；那么下笔之前还是要有点章法的好，所以在实际开发中，要注意自己代码规范啊。。。
假设一种情况
说一点题外话
实际上写html也是无限套娃，不同的是，它从根本上做到的样式结构分离，控件的细节描述，全部交给了css去做，所以页面整体看上去还是满清爽的：
Flutter直接从根本上样式结构不分离，结构上直接从上往上下一套到底
所以，哪里有十全十美的框架，总是有舍有得。。。
新的事物发展，必然会迎来相应的阻力
这里假设一种场景：
角色互换
其实，对于很多言论，我们没必要在意；角色互换，说不定，对方此刻的行为，就是我们自己以后可能会做的事。
其实，我们都是打工人，又何必撕来撕去呢？
通过上面一些代码规范操作后，再配合上GetX的状态管理，相信一般的项目，你都能hold的住了