RyanCW
nutui的坑也不少，2.X版本不维护了，主推3.X版本
对于此PR关联的issue中需要纯异步的场景，switch的onChange事件和switch的状态没有任何关联，而是通过再调用外部弹窗来对状态进行更改场景，只能在onchang事件中直接抛出异常让组件进行识别了。 抛开上面的场景，这个改动还是蛮大的，每个switch的onChange事件只要不是直接使用useState状态的，使用外部接口的都需要判断是否要抛出异常了，否则就可能无法再次点击了
不如参考antd、tdesign、vant等组件库，把loading交给用户来进行控制。 根据onchang的返回值或者onchang抛出错误从数据流向来说感觉不是很对劲呀 反正都是解决方案，希望尽快决定下来，推一个版本。🙂
@oasis-cloud @dushoujun @irisSong 周五了,这周的发版也还修改这个方案吗？ 您们可以讨论决定一下，用那种方案。 确定方案了，如果没时间的话我可以根据您们觉得的方案提个PR
@oasis-cloud #3170 用的antdesign控制的方案
It looks great! Thank you for your work.
@Maihuanyi 直接在 lwIP 层修改在gd32F527这里是正确并可行的，但需要注意： - 确认是否有其他 BSP 在 rt_device_init 阶段修改过 lwIP 的标志位，否则可能引入兼容性问题； - 这种方式会给所有平台带来一定的 ROM 占用开销。 rt_device_init阶段完成不会轻易失败的底层硬件配置，例如时钟、引脚、MAC 基本寄存器、PHY 复位与初始化等。这些操作只要硬件正常，就应当保证成功。 从设计角度看，把严格的 PHY 链路判断放在硬件驱动的基础初始化中，会导致“**物理链路不可用**”被误认为是设备初始化失败。我感觉这是不合理的。 类似gd32 enet_init 函数内判断phy链路状态，应该想办法避免在rt_device_init的时候调用。 在gd32 bsp层做phy的检测逻辑，确认链路建立成功连接后再调用enet_init
你好，这个有新的进展吗