企业官网建设流程全解析

前言

AppStorage很方便，也正因为方便，最容易被用成全局变量仓库。一个页面的弹窗开关、输入框内容、列表筛选条件，全都往里面塞，短期看省事，后面排查刷新问题会很痛苦。

我判断一个状态能不能进AppStorage，只看两点：多个页面是否都要读，变化后是否希望多个页面同步响应。能局部管理的状态，就不要上全局。

为什么这个问题经常被写乱

AppStorage 放全局状态要克制 这类内容很容易被写成“代码能跑就算讲完了”，但对初学者来说，这恰恰是最不够的地方。真正让人卡住的，往往不是某个组件名记不住，而是不知道这段代码为什么要这样拆、状态为什么要这样放、以后需求变化时应该从哪里改。

所以这篇文章不只想给你一个能跑的例子，更想把背后的判断过程讲清楚。你只要把这个判断过程吃透，后面自己改页面、补需求、查问题时，心里会稳很多。

哪些状态适合放进去

主题开关是一个很好的例子。它跨页面生效，子组件也可能直接感知，放在AppStorage里比较合理。

| 登录昵称 | 看场景 | 展示型信息可以，敏感信息要谨慎 |
| 表单输入 | 不适合 | 生命周期短，留在页面内 |
| 弹窗显示 | 不适合 | 页面局部交互 |

全局状态越多，页面之间的隐式依赖越多。后面某个页面改了一个键，另一个页面突然刷新，这类问题很难看出来。

先把页面目标想清楚

在真正写代码之前，先别急着盯着 API。更有用的做法是先想清楚：这个页面到底想解决什么问题，用户最在意的反馈是什么，哪些状态必须一直保持一致。

当你先把这条主线想明白，再回头看组件和状态设计，很多选择都会顺理成章。对小白来说，这一步尤其重要，因为它能帮你从“照着抄”慢慢过渡到“看得懂、改得动”。

完整 ArkTS 示例

下面用主题开关演示AppStorage的合适用法，同时保留一个局部计数器，说明不是所有状态都该全局化。

AppStorage.SetOrCreate<boolean>('darkMode',false)@Componentstruct ThemePreviewCard{@StorageLink('darkMode')darkMode:boolean=falsebuild(){Column({space:8}){Text(this.darkMode?'深色预览':'浅色预览').fontSize(18).fontWeight(FontWeight.Bold).fontColor(this.darkMode?Color.White:'#222222')Text('这个卡片不接收父组件参数，直接响应 AppStorage 的主题变化。').fontSize(13).fontColor(this.darkMode?'#CCCCCC':'#666666')}.alignItems(HorizontalAlign.Start).padding(16).backgroundColor(this.darkMode?'#202124':Color.White).borderRadius(12)}}@Entry@Componentstruct AppStorageThemePage{@StorageLink('darkMode')darkMode:boolean=false@StatelocalCount:number=0build(){Column({space:14}){Row(){Text('主题设置').fontSize(22).fontWeight(FontWeight.Bold)Blank()Toggle({type:ToggleType.Switch,isOn:this.darkMode}).onChange((value:boolean)=>{this.darkMode=value})}.width('100%')ThemePreviewCard()Button(`页面局部计数：${this.localCount}`).width('100%').onClick(()=>{this.localCount+=1})}.padding(16).backgroundColor(this.darkMode?'#111111':'#F5F7FA').height('100%')}}

把关键代码一段段拆开

AppStorage.SetOrCreate<boolean>('darkMode', false)给全局键准备默认值。默认值越早明确，页面第一次读取时越不容易出现状态空洞。

@StorageLink('darkMode')让页面和子组件都绑定同一个全局键。开关变化后，AppStorageThemePage和ThemePreviewCard都会响应，这正是全局状态该发挥作用的地方。

localCount故意保留在@State。这个计数只属于当前页面，放进AppStorage没有任何好处，反而会让别的页面能意外读到它。

命名也要克制

全局键名别写得太随意。像'darkMode'这种还能看懂，如果写成'dm'、'flag1'，过几周自己都不一定记得什么意思。

真实项目里可以把 key 收到常量里，避免不同页面手写字符串写错。这里为了让示例更短，直接写在代码中。

新手最容易踩的坑

这一类示例最容易让人产生错觉：界面出来了，就以为已经掌握了。其实真正容易出问题的地方，通常都在效果之外，比如状态有没有收拢、失败后怎么兜底、以后要扩展时会不会牵一发动全身。

所以你练这篇内容时，别只看“现在能不能跑”，还要继续看“以后好不好改”。能把这个习惯养起来，你写出来的页面会比单纯照着示例拼出来的页面稳很多。

放进真实项目还要补什么

示例代码的重点是把核心思路讲明白，所以很多工程化细节会故意省掉。真正落到项目里时，你通常还要继续补接口联动、异常处理、边界保护、资源抽离，以及和其他页面状态之间的配合。

比较稳的做法是分三步走：先把结构和职责立住，再把真实业务接进去，最后再优化视觉和交互体验。这样改出来的页面不只是“能演示”，而是真的更接近可以长期维护的业务代码。

写在最后

AppStorage适合应用级共识，不适合页面局部情绪。主题、语言、基础用户展示信息可以考虑放进去；表单、弹窗、临时筛选尽量留在页面。全局状态少一点，页面关系就清楚一点。