企业官网建设流程全解析

定西谁做网站,西安做义工网站,谷歌推广公司哪家好,沧县网站制作价格网罗开发 #xff08;小红书、快手、视频号同名#xff09; 大家好#xff0c;我是 展菲#xff0c;目前在上市企业从事人工智能项目研发管理工作#xff0c;平时热衷于分享各种编程领域的软硬技能知识以及前沿技术#xff0c;包括iOS、前端、Harmony OS、Java、Python等…网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。 公众号“Swift社区”每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。 微信端添加好友“fzhanfei”与我直接交流不管是项目瓶颈的求助还是行业趋势的探讨随时畅所欲言。 最新动态2025 年 3 月 17 日快来加入技术社区一起挖掘技术的无限潜能携手迈向数字化新征程文章目录前言状态为什么会“爆炸”不是 Flutter 的锅状态从什么时候开始失控Flutter 和前端状态模型几乎是同构的对比一下两边的状态形态前端 / RNFlutter一个 Flutter 中最典型的“状态开始失控”的例子初期写法状态直接写在页面里Provider / Riverpod / Bloc其实是在解决同一件事一个最基础的 Provider Demo这和 Redux / Zustand 有什么区别RN 项目为什么会掉进 Redux 地狱iOS 状态为什么看起来更“稳定”iOS 的“稳定”来自强约束但代价是什么真正通用的是“状态分层”而不是具体框架一个跨技术栈通用的状态分层模型本地 UI 状态页面业务状态全局状态用 Flutter 再写一版“分层正确”的 Demo总结前言如果你写 Flutter 写到一定阶段迟早会遇到一个问题项目一开始很简单用setState就够了过一阵子开始加 Provider再后来又有人提 Riverpod / Bloc最后大家都在问我们到底该用哪个如果你有前端或者 RN 经验这一幕其实一点都不陌生。Redux、MobX、Zustand、Recoil……前端早就经历过一次完整的“状态管理百家争鸣”。那问题来了为什么 Flutter 这么快就走上了和前端一模一样的路状态为什么会“爆炸”不是 Flutter 的锅先说一个很多人不太愿意承认的事实状态复杂化几乎是所有中大型应用的必经之路。状态从什么时候开始失控你回忆一下项目的演进路径通常是这样的一开始页面里几个变量setState很香业务变复杂表单、列表、筛选条件、分页状态开始增多再后来登录态、用户信息、权限、配置、缓存最后多页面共享状态 异步 回退恢复这时候你会发现一个很现实的问题状态已经不再属于“某一个 Widget / 页面”了。而一旦状态开始跨页面、跨模块存在单纯的 setState 就一定会崩。Flutter 和前端状态模型几乎是同构的这也是为什么 Flutter 会自然长出一堆状态管理方案。因为Flutter 和 React 本质上解决的是同一个问题UI f(State)状态一变就要重新描述 UI。对比一下两边的状态形态前端 / RN组件本地状态页面级状态全局状态用户、配置、权限FlutterWidget 内部 State页面级 StateViewModel / Controller全局 StateProvider / Riverpod你会发现层级是一模一样的只是名字不同。一个 Flutter 中最典型的“状态开始失控”的例子先看一个非常常见的写法。初期写法状态直接写在页面里classUserPageextendsStatefulWidget{overrideStateUserPagecreateState()_UserPageState();}class_UserPageStateextendsStateUserPage{bool loadingfalse;StringuserName;FuturevoidloadUser()async{setState((){loadingtrue;});awaitFuture.delayed(Duration(seconds:1));setState((){userNameTom;loadingfalse;});}overridevoidinitState(){super.initState();loadUser();}overrideWidgetbuild(BuildContextcontext){returnloading?CircularProgressIndicator():Text(Hello$userName);}}一开始看起来没毛病。但问题很快就会出现用户信息被多个页面用页面返回时状态要保留刷新、错误、空态开始增多你会发现页面既负责 UI又负责业务状态又负责异步流程。这一步就是 Flutter 和前端一起迈进“状态复杂区”的开始。Provider / Riverpod / Bloc其实是在解决同一件事很多 Flutter 新手会纠结Provider 和 Riverpod 到底差在哪Bloc 是不是太重了但从设计目标来看它们高度一致把状态从 Widget 中“拎出来”一个最基础的 Provider DemoclassCounterModelextendsChangeNotifier{int count0;voidincrement(){count;notifyListeners();}}voidmain(){runApp(ChangeNotifierProvider(create:(_)CounterModel(),child:MyApp(),),);}classCounterViewextendsStatelessWidget{overrideWidgetbuild(BuildContextcontext){finalcountercontext.watchCounterModel();returnColumn(children:[Text(Count:${counter.count}),ElevatedButton(onPressed:counter.increment,child:Text(Add),),],);}}这和 Redux / Zustand 有什么区别如果你把语言换一下ChangeNotifier ≈ StorenotifyListeners ≈ dispatchwatch ≈ subscribe逻辑结构几乎完全一致。Flutter 并不是“模仿前端”而是在声明式 UI 体系下状态管理只有这一条路能走。RN 项目为什么会掉进 Redux 地狱这件事对 Flutter 其实是一个非常重要的警示。Redux 出问题从来不是因为它“设计不好”而是因为所有状态都被塞进全局 Store页面级、组件级状态没有边界一点小交互也要走 action → reducer结果就是状态集中化过度反而失去可维护性。Flutter 如果无脑全局 Provider / Riverpod结局是一模一样的。iOS 状态为什么看起来更“稳定”很多 iOS 开发者会说我写 UIKit / MVVM很少纠结状态管理。这是因为 iOS 用的是另一套代价体系。iOS 的“稳定”来自强约束页面生命周期固定Controller 持有 View数据流向非常明确你要更新什么就直接调方法。viewModel.userNameTomview.update()不会有“自动重建整棵 UI 树”这件事。但代价是什么状态复用成本高跨页面共享复杂多端复用几乎不可能iOS 的稳定是用灵活性和扩展性换来的。真正通用的是“状态分层”而不是具体框架如果你横向看 Flutter / 前端 / iOS会发现一个共识状态不是越集中越好而是各归其位。一个跨技术栈通用的状态分层模型本地 UI 状态loadingcheckbox 勾选动画开关放在 Widget / Component 内部页面业务状态列表数据表单内容页面筛选条件放在 ViewModel / Controller / Notifier全局状态登录态用户信息配置、权限少而精慎重放全局用 Flutter 再写一版“分层正确”的 DemoclassUserStateextendsChangeNotifier{StringuserName;bool loadingfalse;FuturevoidloadUser()async{loadingtrue;notifyListeners();awaitFuture.delayed(Duration(seconds:1));userNameTom;loadingfalse;notifyListeners();}}classUserPageextendsStatelessWidget{overrideWidgetbuild(BuildContextcontext){finalstatecontext.watchUserState();if(state.loading){returnCircularProgressIndicator();}returnText(Hello${state.userName});}}UI 只关心展示状态逻辑集中页面结构清晰这套结构在 React、Flutter、甚至 SwiftUI 中都成立。总结Flutter 走向“状态管理百家争鸣”不是偶然而是必然声明式 UI → 状态成为核心资产项目变大 → 状态必然外提外提之后 → 就一定会有流派之争