ArkTS 进阶之道19Watch 状态监听边界——为啥改 State 不直接调副作用而要回调本文是「ArkTS 进阶之道」系列第 19 篇开「ArkUI 状态联动」深水区续状态哲学阶段深水区。上五篇讲组件设计篇 63-67Builder/BuilderParam/Styles/Extend/AttributeModifier 绑渲染树/属性/样式类复用。本文讲状态监听边界Watch 荬饰器绑 State 变触发副作用回调——根因在绑状态变副作用回调槽不是 onClick 直接调副作用Watch 荬饰器绑 State 变触发回调记录历史/发请求等副作用onClick 改 State 不直接调副作用违反单向数据流。能力系列篇 19 讲过 Builder 怎么用本文讲为哈 Watch 收副作用回调合法 onClick 直接调副作用违反单向数据流——根因在状态变副作用回调槽绑定。一、开篇Watch 不是 onClick 直接调副作用是绑状态变副作用回调槽的监听荬饰器你写 TypeScript/React 时状态变副作用是「魔法」React 用 useEffect 监听 state 变触发副作用// React 用 useEffect 监听 state 变触发副作用 function Component() { const [count, setCount] useState(0) const [history, setHistory] useState((无)) useEffect(() { setHistory(count${count} 变了useEffect 监听变触发副作用) ← 副作用塞 useEffect 回调 }, [count]) ← 监听 count 变触发副作用回调 return Button onClick{() setCount(count 1)}改 count/Button } // React 用 useEffect 监听 state 变触发副作用是回调魔法你写鸿蒙 ArkTS 时Watch绑状态变副作用回调槽——onClick 改 State 不直接调副作用// ArkTS Watch 绑 State 变触发副作用回调 Entry Component struct Index { State history: string (无) Watch(onCountChange) State watchedCount: number 0 // ✅ Watch 绑 State watchedCount 变触发回调 onCountChange(): void { this.history count${this.watchedCount} 变了Watch 回调记录历史 ← 副作用塞 Watch 回调 } build() { Column() { Button(改 watchedCount) .onClick(() { this.watchedCount }) // ✅ onClick 只改 State副作用塞 Watch 回调 } } } // Watch 绑 State 变触发副作用回调onClick 改 State 不直接调副作用魔法 vs 荬饰器的区别React 把状态变副作用当 useEffect 监听回调回调魔法ArkTS 把 Watch 当「绑状态变副作用回调槽荬饰器」onClick 改 State 不直接调副作用副作用塞 Watch 回调。根因不是魔法是状态变副作用回调槽绑定——Watch 绑 State 变触发副作用回调槽onClick 改 State 不直接调副作用违反单向数据流。二、根因Watch 的状态变副作用回调槽绑定监听机制鸿蒙 ArkUI 的 Watch 是状态变副作用回调槽绑定监听——编译期把 Watch 绑成 State 变的副作用回调槽State 变触发回调槽自动调副作用不是 onClick 直接调副作用来自三重绑定机制。机制 1Watch 编译期绑 State 变副作用回调槽——不是 onClick 直接调Watch 荬饰器编译期绑 State 变副作用回调槽——把 Watch 编成 State 变的副作用回调槽State 变触发回调槽自动调副作用Entry Component struct Index { State history: string (无) Watch(onCountChange) // ✅ Watch 绑 State watchedCount 变副作用回调槽 State watchedCount: number 0 onCountChange(): void { // ✅ 副作用回调槽State 变自动触发 this.history count${this.watchedCount} 变了Watch 回调记录历史 } build() { Column() { Button(改 watchedCount) .onClick(() { this.watchedCount }) // onClick 只改 State副作用塞 Watch 回调 } } } // 编译期Watch(onCountChange) 绑成 State watchedCount 变的副作用回调槽 // 运行时watchedCount 变触发 onCountChange 回调槽自动调副作用记录历史编译期绑副作用回调槽WatchonCountChange荬饰器编译期把回调绑成 StatewatchedCount变的副作用回调槽——watchedCount变触发onCountChange回调槽自动调副作用记录历史。onClick 改 State 不直接调副作用副作用塞 Watch 回调槽。根因不是 onClick 直接调是状态变副作用回调槽绑定。机制 2State 变自动触发回调槽——不用每个改状态地方重复调副作用Watch 荬饰器 State 变自动触发回调槽——不用每个改状态地方重复调副作用绑一次 Watch 全覆盖Entry Component struct Index { State history: string (无) Watch(onCountChange) State watchedCount: number 0 onCountChange(): void { this.history count${this.watchedCount} 变了Watch 回调记录历史 } build() { Column() { Button(改 watchedCount 方式1) .onClick(() { this.watchedCount }) // ✅ 改法1Watch 自动触发副作用 Button(改 watchedCount 方式2) .onClick(() { this.watchedCount 10 }) // ✅ 改法2Watch 自动触发副作用 Button(改 watchedCount 方式3) .onClick(() { this.watchedCount 100 }) // ✅ 改法3Watch 自动触发副作用 } // 三种改法都自动触发 Watch 回调槽不用每个改法重复调副作用 } } // Watch 绑一次三种改法都自动触发回调槽不用每个改状态地方重复调副作用自动触发回调槽全覆盖Watch 绑一次 State 变副作用回调槽——三种改法/ 10/ 100都自动触发回调槽调副作用不用每个改状态地方重复调副作用。根因不是 onClick 重复调是 Watch 绑一次回调槽全覆盖。机制 3onClick 直接调副作用违反单向数据流——副作用塞 Watch 回调onClick直接调副作用违反单向数据流——onClick 应只改状态改 State副作用塞 Watch 回调槽Entry Component struct Index { State history: string (无) State count: number 0 build() { Column() { // ⚠ onClick 直接调副作用能用但违反单向数据流不推荐 Button(改 count 直接调副作用) .onClick(() { this.count // 改 count this.history count${this.count} 变了onClick 直接调副作用不推荐 // ⚠ 直接调副作用能用但违反单向数据流onClick 应只改状态 }) // ✅ onClick 只改 State副作用塞 Watch 回调单向数据流 Button(改 watchedCount副作用塞 Watch 回调) .onClick(() { this.watchedCount }) // ✅ onClick 只改 State副作用塞 Watch 回调 } } } // onClick 直接调副作用违反单向数据流onClick 应只改状态改 State // 副作用塞 Watch 回调槽状态变自动触发副作用onClick 只改状态不调副作用onClick 直接调副作用违反单向数据流onClick 直接调副作用记录历史/发请求等能用但违反单向数据流——onClick 应只改状态改 State副作用塞 Watch 回调槽。单向数据流onClick 改 State → State 变触发 Watch 回调 → 回调调副作用。直接调副作用跳过 Watch 回调槽破坏单向数据流且每个改状态地方都要重复调副作用。机制 4Watch vs onClick 直接调副作用边界——回调槽 vs 直接调Watch绑 State 变副作用回调槽onClick 直接调副作用跳过回调槽直接调——根因都是调副作用但绑的机制不同Entry Component struct Index { State history: string (无) Watch(onCountChange) State watchedCount: number 0 onCountChange(): void { this.history count${this.watchedCount} 变了Watch 回调记录历史 } State count: number 0 build() { Column() { // ✅ Watch 路径onClick 改 State → Watch 回调触发副作用单向数据流 Button(改 watchedCountWatch 回调触发副作用) .onClick(() { this.watchedCount }) // ⚠ 直接调副作用路径onClick 改 State 直接调副作用能用但违反单向数据流 Button(改 count 直接调副作用对比证据) .onClick(() { this.count this.history count${this.count} 变了onClick 直接调副作用不推荐 }) } } } // Watch 路径onClick 改 State → Watch 回调触发副作用单向数据流推荐 // 直接调副作用路径onClick 改 State 直接调副作用能用但违反单向数据流不推荐Watch vs onClick 直接调副作用边界Watch 路径——onClick 改 State → State 变触发 Watch 回调 → 回调调副作用单向数据流推荐。直接调副作用路径——onClick 改 State 直接调副作用能用但违反单向数据流不推荐。根因都是调副作用但绑的机制不同——Watch 绑 State 变副作用回调槽单向数据流onClick 直接调副作用跳过回调槽违反单向数据流。三、真机配图Watch 状态监听边界——绑 State 变触发副作用回调槽初始态count0、watchedCount0、副作用历史无均状态监听边界初始值点调两按钮后watchedCount1 Watch 回调记录历史、count1 onClick 直接调副作用均状态监听边界对比证据齐对比证据点改 watchedCount 按钮后 Watch 回调自动记录历史count1 变了点改 count直接调副作用按钮后 onClick 直接调副作用记录历史count1 变了。Watch 不是 onClick 直接调副作用是绑 State 变副作用回调槽——Watch 荬饰器绑 State 变触发副作用回调槽onClick 改 State 不直接调副作用单向数据流。onClick 直接调副作用能用但违反单向数据流副作用应塞 Watch 回调槽。四、真解法Watch 状态监听的三个场景场景 1Watch 监听 State 变记录历史90% 场景首选副作用塞回调槽Entry Component struct Index { State history: string (无) Watch(onCountChange) State watchedCount: number 0 onCountChange(): void { this.history count${this.watchedCount} 变了Watch 回调记录历史 } build() { Column() { Text(历史${this.history}) Button(改 watchedCount) .onClick(() { this.watchedCount }) // ✅ onClick 只改 State副作用塞 Watch 回调 } } }为哈能跑Watch 监听 State 变记录历史——副作用记录历史塞 Watch 回调槽onClick 改 State 自动触发回调记录历史。首选这个90% 的场景状态变副作用用 Watch 监听 State 变记录历史就够。要写「状态变自动调副作用记录历史等」时用这个——不用 onClick 直接调副作用Watch 绑 State 变副作用回调槽 onClick 只改状态。场景 2Watch 监听 State 变发请求副作用塞回调槽onClick 只改状态Entry Component struct Index { State log: string (无) Watch(onSearchChange) State searchText: string onSearchChange(): void { // ✅ 副作用发请求塞 Watch 回调槽onClick 只改状态 this.log 搜索 ${this.searchText} 变了发请求Watch 回调发请求 // 实际项目http.createHttp().request(...) 发请求塞 Watch 回调槽 } build() { Column() { TextInput({ text: this.searchText, placeholder: 输入搜索词 }) .onChange((value: string) { this.searchText value }) // ✅ onChange 只改 State Text(日志${this.log}) } } } // Watch 监听 searchText 变发请求onChange 改 State searchText → Watch 回调发请求 // 副作用发请求塞 Watch 回调槽onChange 只改状态不直接发请求为哈能跑Watch 监听 State 变发请求——副作用发请求塞 Watch 回调槽onChange 改 State 自动触发回调发请求。要写「状态变自动发请求搜索框变触发搜索等」时用这个——不用 onChange 直接发请求Watch 绑 State 变副作用回调槽 onChange 只改状态。场景 3Watch 监听多 State 变多回调槽各 State 各绑 WatchEntry Component struct Index { State log: string (无) Watch(onNameChange) State name: string // ✅ Watch 绑 name 变副作用回调槽1 Watch(onAgeChange) State age: number 0 // ✅ Watch 绑 age 变副作用回调槽2 onNameChange(): void { this.log name${this.name} 变了Watch 回调槽1 } onAgeChange(): void { this.log age${this.age} 变了Watch 回调槽2 } build() { Column() { TextInput({ text: this.name, placeholder: 姓名 }) .onChange((value: string) { this.name value }) // 改 name 触发回调槽1 TextInput({ text: ${this.age}, placeholder: 年龄 }) .onChange((value: string) { this.age parseInt(value) || 0 }) // 改 age 触发回调槽2 Text(日志${this.log}) } } } // Watch 监听多 State 变各 State 各绑 Watch 回调槽改哪个触发哪个回调槽 // 不用一个回调槽监听多 StateWatch 只监听绑的那个 State多 State 各绑各 Watch为哈能跑Watch 监听多 State 变——各 State 各绑 Watch 回调槽name 绑回调槽1age 绑回调槽2改哪个触发哪个回调槽。要写「多状态各变各触发副作用」时用这个——不用一个回调槽监听多 StateWatch 只监听绑的那个 State多 State 各绑各 Watch。五、一句话哲学Watch 不是 onClick 直接调副作用是绑 State 变副作用回调槽的监听荬饰器。ArkUI 的 Watch 荬饰器编译期绑 State 变副作用回调槽State 变触发回调槽自动调副作用记录历史/发请求等onClick 改 State 不直接调副作用单向数据流。根因不是 onClick 直接调是状态变副作用回调槽绑定——Watch 编译期绑副作用回调槽State 变自动触发 自动触发回调槽全覆盖不用每个改状态地方重复调副作用 onClick 直接调副作用违反单向数据流onClick 应只改状态副作用塞 Watch 回调 Watch vs onClick 直接调副作用边界回调槽 vs 直接调。对比 React useEffect 监听 state 变触发副作用回调ArkTS Watch 绑 State 变副作用回调槽。状态联动深水区开篇串讲Watch 绑 State 变副作用回调槽篇 68onClick 改 State 不直接调副作用单向数据流——开「ArkUI 状态联动」深水区续状态哲学阶段篇 56-59 State/Prop/Link/Provide/Consume/Watch 基础讲状态联动深水区Watch 副作用回调槽边界。系列预告下篇篇 69讲 Link 跨组件双向同步边界父改子改双向同步根因续「ArkUI 状态联动」深水区。五阶段哲学体系类型哲学50-52→ 作用域哲学53-55→ 状态哲学56-59→ 渎染哲学60-62→ 组件设计63-67→ 状态联动深水区68讲清 ArkTS/ArkUI 进阶哲学。能力系列回链能力系列篇本文进阶点篇 19 Builder 用法Watch 状态监听边界根因绑 State 变副作用回调槽篇 13 State 基础用法状态哲学State 赋值就刷 UI 依赖追踪篇 59 Watch 用法本文深水区Watch 副作用回调槽 vs onClick 直接调副作用边界真机 demo 完整代码// 篇 68 demoWatch 状态监听副作用回调 vs onClick 直接调副作用对比 // 对比Watch 绑 State 变触发副作用回调合法 vs onClick 改 State 不直接调副作用 Entry Component struct Index { State count: number 0 State log: string (未操作) State history: string (无) // ✅ 副作用记录 count 变化历史 // ✅ Watch 荬饰器绑 State 变触发副作用回调不直接调副作用 Watch(onCountChange) State watchedCount: number 0 // ✅ Watch 绑 State watchedCount 变触发回调 // ✅ Watch 回调副作用逻辑记录变化历史不在 onClick 里直接调 onCountChange(): void { this.history count${this.watchedCount} 变了Watch 回调记录历史 // ✅ 副作用逻辑塞 Watch 回调里不在 onClick 直接调 } build() { Column({ space: 12 }) { Text(篇 68 配图Watch 状态监听边界) .fontSize(18).fontWeight(FontWeight.Bold).margin({ top: 20, bottom: 8 }) Text(Watch 绑 State 变触发副作用回调 vs onClick 直接调副作用对比证据) .fontSize(12).fontColor(#888).margin({ bottom: 16 }) Column({ space: 6 }) { Text(count ${this.count}).fontSize(15).fontWeight(FontWeight.Bold) Text(watchedCount ${this.watchedCount}).fontSize(15).fontWeight(FontWeight.Bold).fontColor(#2563eb) Text(副作用历史${this.history}).fontSize(12).fontColor(#333).margin({ top: 4 }) Text(日志${this.log}).fontSize(12).fontColor(#333).margin({ top: 4 }) } .width(92%).padding(12).backgroundColor(#f5f5f5).borderRadius(8) // ✅ Watch 路径onClick 改 State watchedCount → Watch 回调触发副作用 Button(改 watchedCountWatch 回调触发副作用) .width(92%).height(44).fontSize(14) .onClick(() { this.watchedCount // ✅ 改 State watchedCountWatch 回调自动触发副作用 this.log 改 watchedCount${this.watchedCount}Watch 回调自动记录历史不直接调副作用 }) // ✅ 直接调副作用路径onClick 改 count 直接调副作用对比证据能用但不推荐 Button(改 count 直接调副作用对比证据) .width(92%).height(44).fontSize(14) .onClick(() { this.count // 改 count this.history count${this.count} 变了onClick 直接调副作用不推荐 // ⚠ 直接调副作用能用但违反单向数据流onClick 应只改状态副作用塞 Watch 回调 this.log 改 count${this.count}onClick 直接调副作用能用但违反单向数据流 }) // ❌ onClick 改 State 直接调副作用违反单向数据流对比证据 // onClick 应只改状态改 State副作用记录历史/发请求等塞 Watch 回调 // 副作用塞 Watch 回调的好处状态变自动触发副作用不用每个改状态地方重复调副作用 } .width(100%).height(100%).alignItems(HorizontalAlign.Center) } }写鸿蒙 ArkUI 记住Watch 不是 onClick 直接调副作用是绑 State 变副作用回调槽的监听荬饰器——Watch 荬饰器编译期绑 State 变副作用回调槽State 变触发回调槽自动调副作用记录历史/发请求等onClick 改 State 不直接调副作用单向数据流。根因不是 onClick 直接调是状态变副作用回调槽绑定——Watch 编译期绑副作用回调槽State 变自动触发 自动触发回调槽全覆盖不用每个改状态地方重复调副作用 onClick 直接调副作用违反单向数据流onClick 应只改状态副作用塞 Watch 回调 Watch vs onClick 直接调副作用边界回调槽 vs 直接调。Watch 监听 State 变记录历史用副作用塞回调槽首选90% 场景Watch 监听 State 变发请求用副作用塞回调槽 onChange 只改状态Watch 监听多 State 变用各 State 各绑各 Watch 回调槽。绑 State 变副作用回调槽不直接调副作用是 ArkUI 状态联动深水区核心
ArkTS 进阶之道19Watch 状态监听边界——为啥改 State 不直接调副作用而要回调本文是「ArkTS 进阶之道」系列第 19 篇开「ArkUI 状态联动」深水区续状态哲学阶段深水区。上五篇讲组件设计篇 63-67Builder/BuilderParam/Styles/Extend/AttributeModifier 绑渲染树/属性/样式类复用。本文讲状态监听边界Watch 荬饰器绑 State 变触发副作用回调——根因在绑状态变副作用回调槽不是 onClick 直接调副作用Watch 荬饰器绑 State 变触发回调记录历史/发请求等副作用onClick 改 State 不直接调副作用违反单向数据流。能力系列篇 19 讲过 Builder 怎么用本文讲为哈 Watch 收副作用回调合法 onClick 直接调副作用违反单向数据流——根因在状态变副作用回调槽绑定。一、开篇Watch 不是 onClick 直接调副作用是绑状态变副作用回调槽的监听荬饰器你写 TypeScript/React 时状态变副作用是「魔法」React 用 useEffect 监听 state 变触发副作用// React 用 useEffect 监听 state 变触发副作用 function Component() { const [count, setCount] useState(0) const [history, setHistory] useState((无)) useEffect(() { setHistory(count${count} 变了useEffect 监听变触发副作用) ← 副作用塞 useEffect 回调 }, [count]) ← 监听 count 变触发副作用回调 return Button onClick{() setCount(count 1)}改 count/Button } // React 用 useEffect 监听 state 变触发副作用是回调魔法你写鸿蒙 ArkTS 时Watch绑状态变副作用回调槽——onClick 改 State 不直接调副作用// ArkTS Watch 绑 State 变触发副作用回调 Entry Component struct Index { State history: string (无) Watch(onCountChange) State watchedCount: number 0 // ✅ Watch 绑 State watchedCount 变触发回调 onCountChange(): void { this.history count${this.watchedCount} 变了Watch 回调记录历史 ← 副作用塞 Watch 回调 } build() { Column() { Button(改 watchedCount) .onClick(() { this.watchedCount }) // ✅ onClick 只改 State副作用塞 Watch 回调 } } } // Watch 绑 State 变触发副作用回调onClick 改 State 不直接调副作用魔法 vs 荬饰器的区别React 把状态变副作用当 useEffect 监听回调回调魔法ArkTS 把 Watch 当「绑状态变副作用回调槽荬饰器」onClick 改 State 不直接调副作用副作用塞 Watch 回调。根因不是魔法是状态变副作用回调槽绑定——Watch 绑 State 变触发副作用回调槽onClick 改 State 不直接调副作用违反单向数据流。二、根因Watch 的状态变副作用回调槽绑定监听机制鸿蒙 ArkUI 的 Watch 是状态变副作用回调槽绑定监听——编译期把 Watch 绑成 State 变的副作用回调槽State 变触发回调槽自动调副作用不是 onClick 直接调副作用来自三重绑定机制。机制 1Watch 编译期绑 State 变副作用回调槽——不是 onClick 直接调Watch 荬饰器编译期绑 State 变副作用回调槽——把 Watch 编成 State 变的副作用回调槽State 变触发回调槽自动调副作用Entry Component struct Index { State history: string (无) Watch(onCountChange) // ✅ Watch 绑 State watchedCount 变副作用回调槽 State watchedCount: number 0 onCountChange(): void { // ✅ 副作用回调槽State 变自动触发 this.history count${this.watchedCount} 变了Watch 回调记录历史 } build() { Column() { Button(改 watchedCount) .onClick(() { this.watchedCount }) // onClick 只改 State副作用塞 Watch 回调 } } } // 编译期Watch(onCountChange) 绑成 State watchedCount 变的副作用回调槽 // 运行时watchedCount 变触发 onCountChange 回调槽自动调副作用记录历史编译期绑副作用回调槽WatchonCountChange荬饰器编译期把回调绑成 StatewatchedCount变的副作用回调槽——watchedCount变触发onCountChange回调槽自动调副作用记录历史。onClick 改 State 不直接调副作用副作用塞 Watch 回调槽。根因不是 onClick 直接调是状态变副作用回调槽绑定。机制 2State 变自动触发回调槽——不用每个改状态地方重复调副作用Watch 荬饰器 State 变自动触发回调槽——不用每个改状态地方重复调副作用绑一次 Watch 全覆盖Entry Component struct Index { State history: string (无) Watch(onCountChange) State watchedCount: number 0 onCountChange(): void { this.history count${this.watchedCount} 变了Watch 回调记录历史 } build() { Column() { Button(改 watchedCount 方式1) .onClick(() { this.watchedCount }) // ✅ 改法1Watch 自动触发副作用 Button(改 watchedCount 方式2) .onClick(() { this.watchedCount 10 }) // ✅ 改法2Watch 自动触发副作用 Button(改 watchedCount 方式3) .onClick(() { this.watchedCount 100 }) // ✅ 改法3Watch 自动触发副作用 } // 三种改法都自动触发 Watch 回调槽不用每个改法重复调副作用 } } // Watch 绑一次三种改法都自动触发回调槽不用每个改状态地方重复调副作用自动触发回调槽全覆盖Watch 绑一次 State 变副作用回调槽——三种改法/ 10/ 100都自动触发回调槽调副作用不用每个改状态地方重复调副作用。根因不是 onClick 重复调是 Watch 绑一次回调槽全覆盖。机制 3onClick 直接调副作用违反单向数据流——副作用塞 Watch 回调onClick直接调副作用违反单向数据流——onClick 应只改状态改 State副作用塞 Watch 回调槽Entry Component struct Index { State history: string (无) State count: number 0 build() { Column() { // ⚠ onClick 直接调副作用能用但违反单向数据流不推荐 Button(改 count 直接调副作用) .onClick(() { this.count // 改 count this.history count${this.count} 变了onClick 直接调副作用不推荐 // ⚠ 直接调副作用能用但违反单向数据流onClick 应只改状态 }) // ✅ onClick 只改 State副作用塞 Watch 回调单向数据流 Button(改 watchedCount副作用塞 Watch 回调) .onClick(() { this.watchedCount }) // ✅ onClick 只改 State副作用塞 Watch 回调 } } } // onClick 直接调副作用违反单向数据流onClick 应只改状态改 State // 副作用塞 Watch 回调槽状态变自动触发副作用onClick 只改状态不调副作用onClick 直接调副作用违反单向数据流onClick 直接调副作用记录历史/发请求等能用但违反单向数据流——onClick 应只改状态改 State副作用塞 Watch 回调槽。单向数据流onClick 改 State → State 变触发 Watch 回调 → 回调调副作用。直接调副作用跳过 Watch 回调槽破坏单向数据流且每个改状态地方都要重复调副作用。机制 4Watch vs onClick 直接调副作用边界——回调槽 vs 直接调Watch绑 State 变副作用回调槽onClick 直接调副作用跳过回调槽直接调——根因都是调副作用但绑的机制不同Entry Component struct Index { State history: string (无) Watch(onCountChange) State watchedCount: number 0 onCountChange(): void { this.history count${this.watchedCount} 变了Watch 回调记录历史 } State count: number 0 build() { Column() { // ✅ Watch 路径onClick 改 State → Watch 回调触发副作用单向数据流 Button(改 watchedCountWatch 回调触发副作用) .onClick(() { this.watchedCount }) // ⚠ 直接调副作用路径onClick 改 State 直接调副作用能用但违反单向数据流 Button(改 count 直接调副作用对比证据) .onClick(() { this.count this.history count${this.count} 变了onClick 直接调副作用不推荐 }) } } } // Watch 路径onClick 改 State → Watch 回调触发副作用单向数据流推荐 // 直接调副作用路径onClick 改 State 直接调副作用能用但违反单向数据流不推荐Watch vs onClick 直接调副作用边界Watch 路径——onClick 改 State → State 变触发 Watch 回调 → 回调调副作用单向数据流推荐。直接调副作用路径——onClick 改 State 直接调副作用能用但违反单向数据流不推荐。根因都是调副作用但绑的机制不同——Watch 绑 State 变副作用回调槽单向数据流onClick 直接调副作用跳过回调槽违反单向数据流。三、真机配图Watch 状态监听边界——绑 State 变触发副作用回调槽初始态count0、watchedCount0、副作用历史无均状态监听边界初始值点调两按钮后watchedCount1 Watch 回调记录历史、count1 onClick 直接调副作用均状态监听边界对比证据齐对比证据点改 watchedCount 按钮后 Watch 回调自动记录历史count1 变了点改 count直接调副作用按钮后 onClick 直接调副作用记录历史count1 变了。Watch 不是 onClick 直接调副作用是绑 State 变副作用回调槽——Watch 荬饰器绑 State 变触发副作用回调槽onClick 改 State 不直接调副作用单向数据流。onClick 直接调副作用能用但违反单向数据流副作用应塞 Watch 回调槽。四、真解法Watch 状态监听的三个场景场景 1Watch 监听 State 变记录历史90% 场景首选副作用塞回调槽Entry Component struct Index { State history: string (无) Watch(onCountChange) State watchedCount: number 0 onCountChange(): void { this.history count${this.watchedCount} 变了Watch 回调记录历史 } build() { Column() { Text(历史${this.history}) Button(改 watchedCount) .onClick(() { this.watchedCount }) // ✅ onClick 只改 State副作用塞 Watch 回调 } } }为哈能跑Watch 监听 State 变记录历史——副作用记录历史塞 Watch 回调槽onClick 改 State 自动触发回调记录历史。首选这个90% 的场景状态变副作用用 Watch 监听 State 变记录历史就够。要写「状态变自动调副作用记录历史等」时用这个——不用 onClick 直接调副作用Watch 绑 State 变副作用回调槽 onClick 只改状态。场景 2Watch 监听 State 变发请求副作用塞回调槽onClick 只改状态Entry Component struct Index { State log: string (无) Watch(onSearchChange) State searchText: string onSearchChange(): void { // ✅ 副作用发请求塞 Watch 回调槽onClick 只改状态 this.log 搜索 ${this.searchText} 变了发请求Watch 回调发请求 // 实际项目http.createHttp().request(...) 发请求塞 Watch 回调槽 } build() { Column() { TextInput({ text: this.searchText, placeholder: 输入搜索词 }) .onChange((value: string) { this.searchText value }) // ✅ onChange 只改 State Text(日志${this.log}) } } } // Watch 监听 searchText 变发请求onChange 改 State searchText → Watch 回调发请求 // 副作用发请求塞 Watch 回调槽onChange 只改状态不直接发请求为哈能跑Watch 监听 State 变发请求——副作用发请求塞 Watch 回调槽onChange 改 State 自动触发回调发请求。要写「状态变自动发请求搜索框变触发搜索等」时用这个——不用 onChange 直接发请求Watch 绑 State 变副作用回调槽 onChange 只改状态。场景 3Watch 监听多 State 变多回调槽各 State 各绑 WatchEntry Component struct Index { State log: string (无) Watch(onNameChange) State name: string // ✅ Watch 绑 name 变副作用回调槽1 Watch(onAgeChange) State age: number 0 // ✅ Watch 绑 age 变副作用回调槽2 onNameChange(): void { this.log name${this.name} 变了Watch 回调槽1 } onAgeChange(): void { this.log age${this.age} 变了Watch 回调槽2 } build() { Column() { TextInput({ text: this.name, placeholder: 姓名 }) .onChange((value: string) { this.name value }) // 改 name 触发回调槽1 TextInput({ text: ${this.age}, placeholder: 年龄 }) .onChange((value: string) { this.age parseInt(value) || 0 }) // 改 age 触发回调槽2 Text(日志${this.log}) } } } // Watch 监听多 State 变各 State 各绑 Watch 回调槽改哪个触发哪个回调槽 // 不用一个回调槽监听多 StateWatch 只监听绑的那个 State多 State 各绑各 Watch为哈能跑Watch 监听多 State 变——各 State 各绑 Watch 回调槽name 绑回调槽1age 绑回调槽2改哪个触发哪个回调槽。要写「多状态各变各触发副作用」时用这个——不用一个回调槽监听多 StateWatch 只监听绑的那个 State多 State 各绑各 Watch。五、一句话哲学Watch 不是 onClick 直接调副作用是绑 State 变副作用回调槽的监听荬饰器。ArkUI 的 Watch 荬饰器编译期绑 State 变副作用回调槽State 变触发回调槽自动调副作用记录历史/发请求等onClick 改 State 不直接调副作用单向数据流。根因不是 onClick 直接调是状态变副作用回调槽绑定——Watch 编译期绑副作用回调槽State 变自动触发 自动触发回调槽全覆盖不用每个改状态地方重复调副作用 onClick 直接调副作用违反单向数据流onClick 应只改状态副作用塞 Watch 回调 Watch vs onClick 直接调副作用边界回调槽 vs 直接调。对比 React useEffect 监听 state 变触发副作用回调ArkTS Watch 绑 State 变副作用回调槽。状态联动深水区开篇串讲Watch 绑 State 变副作用回调槽篇 68onClick 改 State 不直接调副作用单向数据流——开「ArkUI 状态联动」深水区续状态哲学阶段篇 56-59 State/Prop/Link/Provide/Consume/Watch 基础讲状态联动深水区Watch 副作用回调槽边界。系列预告下篇篇 69讲 Link 跨组件双向同步边界父改子改双向同步根因续「ArkUI 状态联动」深水区。五阶段哲学体系类型哲学50-52→ 作用域哲学53-55→ 状态哲学56-59→ 渎染哲学60-62→ 组件设计63-67→ 状态联动深水区68讲清 ArkTS/ArkUI 进阶哲学。能力系列回链能力系列篇本文进阶点篇 19 Builder 用法Watch 状态监听边界根因绑 State 变副作用回调槽篇 13 State 基础用法状态哲学State 赋值就刷 UI 依赖追踪篇 59 Watch 用法本文深水区Watch 副作用回调槽 vs onClick 直接调副作用边界真机 demo 完整代码// 篇 68 demoWatch 状态监听副作用回调 vs onClick 直接调副作用对比 // 对比Watch 绑 State 变触发副作用回调合法 vs onClick 改 State 不直接调副作用 Entry Component struct Index { State count: number 0 State log: string (未操作) State history: string (无) // ✅ 副作用记录 count 变化历史 // ✅ Watch 荬饰器绑 State 变触发副作用回调不直接调副作用 Watch(onCountChange) State watchedCount: number 0 // ✅ Watch 绑 State watchedCount 变触发回调 // ✅ Watch 回调副作用逻辑记录变化历史不在 onClick 里直接调 onCountChange(): void { this.history count${this.watchedCount} 变了Watch 回调记录历史 // ✅ 副作用逻辑塞 Watch 回调里不在 onClick 直接调 } build() { Column({ space: 12 }) { Text(篇 68 配图Watch 状态监听边界) .fontSize(18).fontWeight(FontWeight.Bold).margin({ top: 20, bottom: 8 }) Text(Watch 绑 State 变触发副作用回调 vs onClick 直接调副作用对比证据) .fontSize(12).fontColor(#888).margin({ bottom: 16 }) Column({ space: 6 }) { Text(count ${this.count}).fontSize(15).fontWeight(FontWeight.Bold) Text(watchedCount ${this.watchedCount}).fontSize(15).fontWeight(FontWeight.Bold).fontColor(#2563eb) Text(副作用历史${this.history}).fontSize(12).fontColor(#333).margin({ top: 4 }) Text(日志${this.log}).fontSize(12).fontColor(#333).margin({ top: 4 }) } .width(92%).padding(12).backgroundColor(#f5f5f5).borderRadius(8) // ✅ Watch 路径onClick 改 State watchedCount → Watch 回调触发副作用 Button(改 watchedCountWatch 回调触发副作用) .width(92%).height(44).fontSize(14) .onClick(() { this.watchedCount // ✅ 改 State watchedCountWatch 回调自动触发副作用 this.log 改 watchedCount${this.watchedCount}Watch 回调自动记录历史不直接调副作用 }) // ✅ 直接调副作用路径onClick 改 count 直接调副作用对比证据能用但不推荐 Button(改 count 直接调副作用对比证据) .width(92%).height(44).fontSize(14) .onClick(() { this.count // 改 count this.history count${this.count} 变了onClick 直接调副作用不推荐 // ⚠ 直接调副作用能用但违反单向数据流onClick 应只改状态副作用塞 Watch 回调 this.log 改 count${this.count}onClick 直接调副作用能用但违反单向数据流 }) // ❌ onClick 改 State 直接调副作用违反单向数据流对比证据 // onClick 应只改状态改 State副作用记录历史/发请求等塞 Watch 回调 // 副作用塞 Watch 回调的好处状态变自动触发副作用不用每个改状态地方重复调副作用 } .width(100%).height(100%).alignItems(HorizontalAlign.Center) } }写鸿蒙 ArkUI 记住Watch 不是 onClick 直接调副作用是绑 State 变副作用回调槽的监听荬饰器——Watch 荬饰器编译期绑 State 变副作用回调槽State 变触发回调槽自动调副作用记录历史/发请求等onClick 改 State 不直接调副作用单向数据流。根因不是 onClick 直接调是状态变副作用回调槽绑定——Watch 编译期绑副作用回调槽State 变自动触发 自动触发回调槽全覆盖不用每个改状态地方重复调副作用 onClick 直接调副作用违反单向数据流onClick 应只改状态副作用塞 Watch 回调 Watch vs onClick 直接调副作用边界回调槽 vs 直接调。Watch 监听 State 变记录历史用副作用塞回调槽首选90% 场景Watch 监听 State 变发请求用副作用塞回调槽 onChange 只改状态Watch 监听多 State 变用各 State 各绑各 Watch 回调槽。绑 State 变副作用回调槽不直接调副作用是 ArkUI 状态联动深水区核心
