业务组件
推动@fs/smart-design组件库搭建的必要性？
- 如果这一步不做，就很难推动UI设计规范的落地，即无法保证UI设计在整个B端体系统一，对开发对设计师都会带来很多重复繁杂的工作量，且沟通成本巨大
- 做的方案有很多，为何要逐个二次包装？长远来看，基于第三方组件库的二次包装极有必要，特别是在早期组件库不成熟的情况下，优势特别明显，即无法抹平因官方版本变动导致的API差异
定位
基于业务梳理常用组件，现阶段仅包含PC端，后续根据需求可逐步封装移动端，客户端相关业务侧组件
注意📢
注意，除组件表现行为外，所有业务逻辑都应该共用。如统一的多语言管理，权限管理等。任何组件API变动，都应考虑向下兼容。
非必要不要产生BreakChange。
解决什么问题？
- 统一业务开发规范，关注点分离，将开发人员的精力往业务逻辑上集中，尽量减少布局及样式的关注，B端业务开发往往很少编写样式，布局信息。
- 集中管理通用业务组件，通用能力，提高复用，同时保证易维护易迭代，若未来通用模块UI或交互形式改变，只需升级依赖即可，无需侵入业务系统。