从一张组网页面看状态驱动界面：SoftBus 演示页的真实行为与调试记录

这篇文章只讨论 ohos/entry/src/main/ets/pages/Index.ets 的实际代码，以及它运行后能看到的界面。页面标题写着“SoftBus 设备组网”，内容也出现了“设备发现”“数据传输”“任务流转”等词，因此很容易让人以为这已经是一个两台设备之间能发现、连接和传数据的分布式应用。先把结论放在前面：它不是。当前工程没有导入分布式软总线相关模块，没有申请或处理发现、认证、建链、收发数据的能力，也没有第二台设备参与。它是一个很适合初学者阅读的 ArkUI 单页交互样例，用三个 @State 字段把“未连接”和“已连接”的视觉状态模拟出来。

这并不降低它的学习价值。相反，把演示层和真实系统能力分开，正好能练习一件开发中非常重要的事：根据源码判断页面究竟做了什么，而不是根据标题、按钮文案或设计意图推断它做了什么。这个页面的代码很短，但包含了声明式 UI 的几个基本环节：入口如何进入页面、状态如何写入、文本和按钮如何读取状态、禁用态如何表达、一次点击为什么会让多个地方一起变化。下面会把这些环节逐个拆开，并给出能在 DevEco Studio 中复现的检查步骤。

1. 先确认工程从哪里启动

页面所在的工程采用 Stage 模型。entry/src/main/ets/entryability/EntryAbility.ets 中的 EntryAbility 继承自 UIAbility，在 onWindowStageCreate 回调里执行 windowStage.loadContent('pages/Index')。这句话确定了窗口创建后要加载的页面路由是 pages/Index。entry/src/main/resources/base/profile/main_pages.json 也只列出了 pages/Index，因此本工程没有多页跳转链路；读者启动应用时看到的就是本文分析的 Index 页面。

在 Index.ets 顶部，@Entry 表示这个自定义组件是页面入口，@Component 表示它是 ArkUI 组件，结构体名称为 Index。页面没有引入业务服务、网络客户端或设备管理类，所有内容都直接写在这个组件的 build() 函数里。对于一个教学性质的单页来说，这种写法便于从上到下对应界面；但它也意味着没有独立的数据层、没有异步过程、没有页面之间传参。阅读时应把它理解为“状态与视图关系的最小示例”，不要把它当成完整的分布式通信架构。

应用模块配置中的 deviceTypes 为 phone，说明当前配置的目标设备类型是手机。页面中“平板 MatePad”是一条固定文本，不来自真实扫描结果，也不意味着工程会在平板上运行或能自动识别某个具体设备。固定命名在演示里有助于让卡片看起来像一条设备记录，但它不是设备标识、设备列表或可信设备认证结果。

2. 首屏到底包含了哪些内容

根容器是一个垂直 Column，设置了 space: 16，并通过 width('100%')、height('100%') 充满可用区域。它有 18 的内边距，背景为 #F8FAFC。这解释了首屏上内容没有紧贴屏幕边缘、各块之间有规律留白的原因。代码没有使用 Scroll 或 List，所以这里是一张固定高度的页面；在当前这些内容和手机截图的尺寸下能完整放下，但源码没有提供滚动保障。若后续文字、字体或系统缩放变大，是否仍能全部显示，需要实际设备验证，不能仅从目前截图推定。

根 Column 从上到下包含四个区域。第一块是标题 Text('SoftBus 设备组网')，字号 26、粗体、颜色 #0C4A6E。紧接着的副标题是“发现可信设备后建立会话通道，再传输跨端数据。”，字号 14、灰蓝色 #64748B。这两行只是页面的说明文本，没有对应任何条件判断；无论连接状态怎样，它们都保持不变。

第三块是淡青色设备卡片。卡片也是一个 Column，内部间距为 12，宽度占满父容器，内边距 18，背景 #ECFEFF，圆角 20。卡片第一行是 Row：左侧为粗体的“平板 MatePad”，右侧为状态词。左侧文本设置 layoutWeight(1)，会在这一行优先占用剩余空间，从而把右侧状态推到行尾。右侧文字由 this.connected ? '已连接' : '可发现' 生成，并且字体颜色也由同一个布尔值决定：已连接时为绿色 #15803D，未连接时为灰色 #64748B。

卡片第二行直接显示 this.channel。初始值是“未建立连接”。第三行是会话按钮：当 connected 为 false，按钮文案为“建立 SoftBus 会话”、背景为青蓝色 #0E7490；当它为 true，文案变为“断开设备”、背景变为红色 #DC2626。这三处变化——状态词、状态词颜色、按钮文案和按钮颜色——都来自同一个布尔状态，因此用户一次点击后会看到一组一致的视觉反馈。

第四块是白色的数据传输卡片。标题“数据传输”字号 18、粗体；下一行在源码中写作单引号字符串 Text('已发送 ${this.packets} 个数据包')；最后是蓝色“发送状态同步”按钮。该按钮调用 .enabled(this.connected)，所以初始状态下不可点，截图中它呈现为浅色的禁用态。启用条件没有额外逻辑：只要 connected 是真就能点，断开后立即不能点。

页面最下方还有淡绿色能力说明卡，标题为“软总线能力”，内容为“设备发现 · 数据传输 · 设备组网 · 任务流转”。它是静态文字，没有按钮，没有状态引用，也没有与上方会话卡的联动。把它看作这张示意页希望表达的能力方向是合适的；把它当作当前工程已经实现的四项功能则不符合源码。

3. 三个状态字段各自负责什么

Index 中只声明了三个响应式字段：

@State connected: boolean = false
@State channel: string = '未建立连接'
@State packets: number = 0

connected 是一个布尔值，初始为 false。它是这张页面的主开关：设备状态文字、设备状态颜色、会话按钮的标题、会话按钮的背景颜色以及发送按钮是否可用，都读取它。因为这些视图表达的是同一种“当前是否连上”的模拟状态，所以共用一个字段是自然的。若每一个显示位置各自保存状态，点击后就容易发生标题已更新而按钮仍是旧颜色的情况；此处把它们都推导自 connected，正好避免了这种不同步。

channel 是字符串，初始为“未建立连接”。它负责显示更具体的会话说明，而不是作为判定连接与否的唯一依据。连接时，点击回调把它写为“会话 ID SB-2048 · 高速通道已就绪”；断开时又写回初值。这里的 SB-2048 是界面使用的固定文案，不是接口返回的会话 ID。阅读这个字段时应注意：它展示的是模拟结果，并没有任何真实通道对象与它绑定。

packets 是数字，初始为零。发送按钮的回调会执行 this.packets++，因此每一次可用状态下的点击都会令内存中的数值加一。这个递增本身确实发生了，也是本页第三个响应式字段的写入点。不过，当前显示文本用了普通单引号，而不是反引号模板字符串，也没有写成字符串拼接。因此 ${this.packets} 在屏幕上被按字面量显示，首屏截图就能看到“已发送 ${this.packets} 个数据包”。也就是说，状态会变，但这行文字并没有读取到它，用户看不到数字从零变成一、二、三。这是当前工程一个可观察到的实现问题，而不是截图或设备异常。

这个细节值得初学者认真对待。声明 @State 并不会自动让所有相近名字的文本更新；视图必须在表达式里实际依赖这个状态。若仅从“有 packets++”推断“计数已经显示”，就会漏掉模板字符串的语法差异。本文不修改源码，但如果以后要修正显示，应把单引号改为反引号，或者显式拼接字符串；修正后再验证文本是否随每次点击改变。这是一个后续改动建议，不是当前页面已有的能力。

4. 点击“建立 SoftBus 会话”时实际执行了什么

会话按钮绑定的回调可以展开成三步：先反转 connected，再根据反转后的值重写 channel。源码把它压在同一行：

.onClick(() => {
  this.connected = !this.connected
  this.channel = this.connected
    ? '会话 ID SB-2048 · 高速通道已就绪'
    : '未建立连接'
})

首次点击前，connected 为 false。!false 得到 true，赋值完成后，条件表达式读取到的是新的真值，所以 channel 被设成“会话 ID SB-2048 · 高速通道已就绪”。ArkUI 随后依据这两个状态重新计算引用它们的组件属性：右侧文字由“可发现”变为“已连接”，文字颜色由灰色变为绿色，第二行显示新的会话文案，按钮自身变为“断开设备”且背景换成红色，发送按钮解除禁用。

再次点击时，流程完全相反。connected 从真变假，channel 回到“未建立连接”，所有依赖布尔值的属性也回到初始样式。代码没有防抖、确认框、加载动画、错误分支或异步等待，所以每次点击都是立即切换本地状态。连续快速点击时，最终界面只取决于点击次数是奇数还是偶数；它不会向某个服务发出多条连接或断开请求，因为工程中根本没有这类请求。

从交互设计的角度看，这个回调展示了“状态为唯一事实来源”的小型例子。代码没有寻找某个文本组件并直接改文字，也没有调用按钮对象去改颜色。开发者只改两个数据字段，build() 中的条件表达式决定下一帧应该长成什么样子。这样做的好处是逻辑路径短：排查“为什么按钮仍然不可用”时，只需检查 connected 是否为真，以及 .enabled(this.connected) 是否仍存在；不必追踪多处手工 UI 赋值。

但这里的“会话”只是一种界面状态。真实的分布式连接通常会有设备发现、用户选择、授权或认证、连接过程、成功与失败回调、可用性改变、断连清理等多个阶段。当前布尔值只有两种状态，不能表达“连接中”“连接失败”“设备离线”等情形；固定字符串也无法表达不同设备和不同错误。若将来接入真实能力，应重新设计状态模型，而不能仅仅把某个 API 调用塞进这个点击回调。

5. 发送按钮为什么有禁用态，又为什么没有真实发送

Button('发送状态同步') 后面链式调用了 .enabled(this.connected)。在 connected 为假时，组件禁用，用户无法触发它的 onClick；在真时，按钮可操作，点击会执行 this.packets++。这是一种非常直观的前置条件表达：先在页面层建立会话，再允许进行页面所称的“状态同步”。初始截图中浅蓝色按钮与不能点击的状态相对应，建立模拟会话后才会进入可用状态。

应该区分“按钮可点击”与“数据已发送”。当前回调内部没有字符串、字节数组、设备标识、会话句柄、网络调用、回调注册或传输结果处理，只有数字自增。因此，点击它不会把任何数据从手机送到平板，也不会产生真实数据包。packets 这个变量名和按钮文案描述了一种教学情境，不构成协议层计数。哪怕把插值语法修正为反引号，页面最多也只是把“本地点击次数”展示为一个数字，仍不能证明网络传输成功。

这种边界在写演示文章时尤其重要。很多示例会用一颗按钮和一段“发送成功”的提示来讲解交互，但一旦标题带有设备、会话、跨端这些词，读者就可能在真实项目里据此做错误的架构判断。这里更准确的表述是：页面用 enabled 展示了一个由连接状态控制的操作入口，用 packets++ 演示数字状态的更新意图；由于显示字符串没有插值、也没有传输 API，当前界面没有可见的数据包计数，也没有实际发送行为。

从测试顺序看，先验证禁用规则，再验证回调是否能触发会更清楚。启动后直接点发送按钮，预期它不可用；建立会话后再点，预期回调才具备执行条件。由于界面文字的插值问题，不能把“文字没变”直接当作回调没执行；应在调试器中观察 packets，或在后续修正显示语法后通过数字变化验证。这样能把“状态写入是否成功”与“视图是否正确读取状态”分成两个问题处理。

6. 用组件树读懂版式，而不是凭截图猜布局

页面没有复杂的嵌套。最外层 Column 依次装入标题、说明、设备卡、传输卡、能力卡。Column({ space: 16 }) 控制一级区域的垂直距离；设备卡自身的 Column({ space: 12 }) 和传输卡的 Column({ space: 10 }) 再控制卡片内元素的距离；能力卡的内部间距更小，为 7。不同间距并不是隐藏的设计系统，而是直接写死在当前页面的数值。它们让标题与卡片、卡片内部的行和按钮之间呈现不同的疏密。

设备卡的首行使用 Row，这是唯一的横向布局。左侧设备名使用 layoutWeight(1)，右侧状态词未设置固定宽度。常见的理解是左侧参与剩余空间分配，右侧按自身内容宽度布局，因此短的“可发现”和“已连接”会靠近右边。页面并没有设置 justifyContent、显式对齐方式或截断规则；当设备名换成很长的文本时，实际展示可能受屏宽和文本布局影响，需要运行验证。当前固定的“平板 MatePad”在截图中没有出现挤压问题，并不代表任意设备名都能安全显示。

多个 Text 使用 .width('100%')，目的是让它们按父容器宽度排布。标题和副标题也这样设置，所以它们并不是根据文本自身宽度居中或收缩。两个主要卡片都使用 18 的 padding，能力卡使用 17；圆角分别为 20、20 和 18。浅灰页面底色配合淡青、白、淡绿三种卡片背景，帮助用户把“设备”“传输”“能力说明”分为三段。这里没有阴影、边框或图片资源来做层次，视觉分区主要依赖背景色、圆角、留白和字号。

字体也遵循简单层级。主标题为 26，卡片标题和设备名为 18，能力卡标题为 17，说明与状态信息主要是 14 或 15。FontWeight.Bold 只给了主标题、设备名、传输标题和能力标题；会话提示、设备状态和说明均使用普通字重。由于颜色值是源码中明确可见的常量，分析可以精确到色号；但不应凭借配色推断无障碍对比度已经通过检验。当前代码未设置语义标签、辅助功能说明或动态字体处理，是否适合特定无障碍场景需要另行测试。

7. 这张页面怎样体现声明式更新

初学 ArkUI 时，经常会把 build() 想成“只在启动时执行的一段搭建界面的代码”。在这张页面里，更有用的理解是：build() 描述了不同状态下界面应该具备的样子。this.connected ? '已连接' : '可发现' 不是主动命令某段文字切换，而是一个关于状态的描述；Button(this.connected ? '断开设备' : '建立 SoftBus 会话') 和 .enabled(this.connected) 也是同样的描述。

当点击回调写入 connected 后，框架可以重新计算依赖该字段的声明。对开发者而言，事件回调只承担“改变数据”这一职责，UI 属性集中保留在组件声明处。这种写法让读代码的路径比较直接：先找到字段，再搜索 this.connected，就能列出页面所有受它影响的地方。当前文件体量很小，依赖关系一眼可见；在组件变多后，这种清晰的状态来源仍是维护页面的基础。

channel 则展示了另一类状态：不适合只由布尔值在视图中直接拼出的说明文本。它在点击时被赋成两种完整字符串，Text(this.channel) 无条件显示它。这样写的优点是文案集中在状态变更处，缺点是状态含义与文案耦合较紧。对当前两种情形而言没有问题；如果未来有多设备、多错误码或多阶段，单一字符串会变得难以分析，最好让设备对象、连接阶段和错误信息分别表达，再由视图选择合适文案。这个判断来自状态规模的变化，并不是说当前短示例必须拆分。

packets 提醒我们，声明式关系必须写对语法。@State 只负责让字段成为可被观察的状态，不会把名字中的数字自动映射到任何 Text。只有当文本使用反引号模板字符串，如 Text(`已发送 ${this.packets} 个数据包`)，或通过拼接引用 this.packets 时，框架才会把这个字段纳入该文本的依赖。当前单引号写法没有产生这个依赖，截图所呈现的字面量正是验证证据。

8. 不要把旧组件文件当成当前页面功能

工程目录下还有 legacy_components_unused 文件夹，里面能看到名称含有 SoftBus、DeviceList、Connect、StateMonitor、BestPractice 的 .ets 文件。它们不在 main_pages.json 指定的路由列表中，EntryAbility 也没有加载它们，当前 Index.ets 没有导入它们。本文的结论只以实际入口页面和它能抵达的代码为准，不把这些未被当前入口使用的文件描述成这款应用已经展示的模块。

同样地，模块目录内存在构建输出或 HAP 文件，只能说明工程曾经被构建过，不能替代对源代码和运行页面的判断。本文保留的两张页面截图与 Index.ets 的结构相符：首屏为可发现、未建立连接且发送按钮禁用；操作后为已连接、出现固定会话文案且按钮变为断开。代码截图也可作为核对文本、状态字段和链式属性的辅助材料。它们不证明真实设备间发生了发现或通信。

9. 关于“SoftBus”应当如何理解

分布式软总线是一个明确的技术主题，但技术名出现在标题中，和工程真正完成接入，是两件不同的事。真实接入通常至少会涉及系统提供的相应 API、设备或会话相关的标识与回调、权限与可信关系的处理、错误和生命周期管理，以及在两端实际验证消息到达。每一项都有平台版本和权限条件，不能凭一张模拟卡片补齐。

当前页面做的是用普通 ArkUI 状态来演示一个容易理解的交互故事：某设备可发现，用户点击建立会话，页面转为已连接，随后可以点击发送。这个故事很适合在产品原型、课堂讲解或状态机入门时使用。若目标是学习真实分布式能力，正确的下一步不是宣称“已有高速通道”，而是先查阅当前 API 版本的官方文档，确定所需能力和设备条件，再把真实回调映射成页面状态。接入成功后，页面的 connected 也不应由点击立即翻转，而应该由真实成功、失败或断开事件驱动。

从页面设计角度，当前“设备发现 · 数据传输 · 设备组网 · 任务流转”可以保留为教育性的能力索引。但发布文章时应紧挨着说明：这四项在此项目中只作为文案出现；实际实现的是本地的连接状态切换和一个受连接状态控制的按钮。这样的说明既不否定示例的教学用途，也避免读者把概念介绍误读为功能清单。

10. 可按步骤复现的运行与检查清单

以下操作不要求两台设备，也不需要网络。它们验证的是当前单页的可见状态，而不是软总线通信。

1. 在 DevEco Studio 打开本目录的 articles/096-SoftBus/ohos 工程，确认入口页面配置仍为 pages/Index，启动目标为手机设备或模拟器。
2. 首次打开应用，检查顶部是否依次显示“SoftBus 设备组网”和副标题；设备卡是否显示“平板 MatePad”“可发现”“未建立连接”；会话按钮是否为“建立 SoftBus 会话”。
3. 不建立会话时，尝试点击“发送状态同步”。应看到该按钮处于不可用状态，不能触发正常点击。这验证 .enabled(this.connected) 在初始 false 下生效。
4. 点击“建立 SoftBus 会话”。检查设备状态是否改为“已连接”、颜色是否变绿、会话行是否显示“会话 ID SB-2048 · 高速通道已就绪”、按钮是否改为“断开设备”并使用红色背景。
5. 在已连接状态下检查“发送状态同步”是否可以点击。连续点击数次后，留意界面文本仍然显示 ${this.packets} 这一字面量。这与当前单引号字符串一致，是应记录的现象。
6. 点击“断开设备”。检查设备状态、会话文本和会话按钮是否全部回到初始状态，同时发送按钮再次禁用。packets 没有在断开回调中清零，虽然页面没有正确显示数值，但从源码可知断开不会重置它。
7. 重复建立与断开数次。由于当前回调不包含异步任务或错误处理，预期每一次切换立即完成，不会出现加载中或失败提示。
8. 如需核对布局，分别与本文保留的初始图和操作图对照：三个卡片顺序、圆角背景、顶部标题、传输按钮的禁用与启用状态应一致。不要把截图中的系统状态栏信息当成应用内容。

这份清单还有一个边界：它只能证明页面的本地状态逻辑和样式输出符合代码。要验证真实发现、会话建立或跨端数据到达，必须另行接入相关系统能力，并在具备条件的真实设备环境中设计双端测试、异常测试与权限测试。

11. 读这个示例时最容易出现的四种误判

第一种误判是把“可发现”当成扫描结果。当前字符串完全由 connected 反向决定：未连接即显示可发现，连接即显示已连接；没有扫描按钮、扫描列表和结果回调。它表达的是一个预设设备的演示状态。

第二种误判是把“会话 ID SB-2048”当成真实标识。它写死在点击回调中，每次连接都会显示同一个值，没有生成逻辑，没有保存对象，也没有对端参与。它的作用只是让连接后的界面看起来更具体。

第三种误判是把按钮放开当成传输成功。.enabled 只控制交互可用性，packets++ 只修改本地数字；两者均没有传输层含义。真正的发送至少需要可用通道和可观察的发送结果，这些在当前文件中都不存在。

第四种误判是认为变量变化就一定会在每个相关文本中显示。首屏截图已经给出反例：packets 的名字确实出现在字符串中，但因为使用单引号，文本没有引用字段的实际值。开发时应同时阅读状态更新语句和视图表达式，而不是只看其中一端。

12. 从这个小页面能带走什么

如果只把它当作“SoftBus 示例”，很容易因功能边界而失望；如果把它当作 ArkUI 状态联动练习，它恰好足够聚焦。一个布尔值同时控制状态标签、色彩、按钮文案和另一个按钮的可用性；一个字符串承载连接后的可见说明；一个数字展示了状态递增的写法以及模板字符串写错后的真实后果。组件树也足够短，初学者可以从 build() 顶部一路对照到屏幕底部。

更重要的是，这个工程训练了如实描述代码的习惯。页面可以使用“设备组网”这个题材来组织界面，但文章不能把静态文案写成已经实现的发现能力，也不能把本地加一写成已发送的数据包。把已实现内容、可见缺陷和后续扩展分开，技术说明才具有可复核性。

当前已实现的内容可以简洁归纳为：Stage 模型入口加载 Index；单页使用 Column、Row、Text、Button 组成三张卡片；“建立/断开”点击会切换本地连接状态与会话说明；发送按钮随连接状态禁用或启用；可用状态下点击会使 packets 自增。当前未实现的内容同样应明确：真实设备发现、可信认证、真实会话建立、跨设备数据传输、真实包计数、失败处理、加载过程、多设备列表和页面导航。

当你准备把类似原型演进为真实分布式应用时，可以先保留这种“状态决定视图”的结构，再用真实回调替代直接取反的模拟写法，并补齐中间状态与错误状态。那将是另一个实现阶段。对本目录的这份代码而言，最准确的结论仍然是：它完成了一个清晰的本地交互演示，而非真正的 SoftBus 通信接入。

13. 用状态表把两个交互分开验证

代码只有三个字段，却有两个独立的点击入口。为了避免把页面行为混在一起，可以在阅读时先列一张很小的状态表。初始时，connected 为假，channel 为“未建立连接”，packets 为零。此时设备右侧显示“可发现”，主按钮显示“建立 SoftBus 会话”，发送按钮禁用。点击主按钮后，前两个字段会一起变化，packets 保持原值；设备卡和发送按钮都因为 connected 变为真而改变。再点击发送按钮，只应影响 packets，不会改写 connected 或 channel。最后点击断开，前两个字段回到初始表现，packets 仍然不被清零。

这张表反映出一个经常被忽略的事实：页面没有“重新开始”操作。断开动作只是切换连接布尔值和会话说明，并不重置本地点击次数。由于当前计数文本没有正确引用变量，读者在屏幕上看不见这个差异；但从源代码的赋值路径可以判断它存在。如果后续修复了文本插值，再先连接、发送两次、断开、重连，显示的数值会继续累计而不是回到零。是否应该清零是产品规则，不是 ArkUI 的自动行为；当前工程没有为它作出显式选择。

从“谁能改写谁”的角度看，connected 只在会话按钮的回调中赋值，channel 也只在这个回调中赋值，packets 只在发送按钮回调中自增。没有生命周期方法、定时器、网络回调或子组件能够在后台修改它们。因此页面静止时不会自行从“可发现”变成“已连接”，也不会自行增长数据包数。这个静态特征让演示易于复现，也说明它无法呈现真实设备上下线等外部事件。

这种审阅方式比只看按钮文案可靠。按钮名字是面向用户的语言，状态表才是实现的语言。尤其当项目以后变大时，先确定字段初始值、写入点、读取点和是否重置，能快速发现很多看起来像样式问题、实际是状态定义问题的错误。这个示例中的模板字符串失效就是一个典型例子：写入点存在，读出点却没有真正引用数据。

14. 在 DevEco Studio 中怎样定位计数显示问题

无需改动业务逻辑，也可以在调试时验证 packets 是否增加。先在发送按钮的 onClick 行设置断点，运行应用并建立页面中的模拟会话。因为按钮在未连接时被禁用，必须先让 connected 变成真，否则无法走到该断点。点击“发送状态同步”后，调试器应停在 this.packets++ 附近；单步执行后查看当前组件实例中的 packets，它会比执行前大一。

此时再观察屏幕，文字仍不会从字面量变成数字。不要误以为调试器和界面出现矛盾：二者恰好共同说明了问题的位置。状态写入已经完成，而视图的参数并不是模板字符串。ArkTS 和 TypeScript 中，反引号用于把 ${...} 解释为插值表达式；单引号包住的内容则是普通字符序列。当前截图把美元符号、花括号和字段名都显示出来，正是单引号被原样保留的结果。

如果仅为学习而在个人副本里验证修复，可把这行改成实际引用 this.packets 的写法，再重新运行。本文不对工程作此修改，也不把它计为现有功能。修复后应重复测试三个点：首次建立会话后数值是否从零开始可见；每次点击是否恰好增加一；断开再连接后数值是否按当前状态逻辑继续保留。第三点尤其能提醒开发者，修复展示与改变重置规则是两项不同的改动，不能混为一谈。

调试时还可以在会话回调两条赋值语句上分别停住。第一次赋值后，connected 已是真，而 channel 还可能处于旧值；回调结束、框架完成界面刷新后，用户才看到两者对应的完整新状态。对于这个同步、短小的回调来说，这个中间时刻不会形成可交互的界面。但理解赋值顺序仍有价值：条件表达式读取的是已经被反转后的 connected，所以连接时才会选择“高速通道已就绪”这条固定文案。

15. 页面样式中的可验证事实与不可推断结论

本文可以直接从代码确认的样式事实包括：根背景为 #F8FAFC；设备卡为 #ECFEFF；传输卡为白色；能力卡为 #F0FDF4；连接按钮在未连接时为 #0E7490，连接后为 #DC2626；发送按钮声明的背景为 #2563EB。它们与保留截图呈现出的浅色卡片和蓝、红操作按钮相互吻合。状态文字的颜色也可以直接核对：未连接使用 #64748B，连接使用 #15803D。

但是，有些结论不能仅凭这些色号得出。源码没有声明深色模式分支，不能称其已经支持深色模式；没有声明横屏布局，不能称其已经为横屏优化；没有包裹滚动容器，不能保证各种字号下都不会溢出；没有设置点击后的额外反馈，不能称其具有加载、成功或失败提示。截图只覆盖一个手机尺寸和两个状态，也不能替代在不同设备密度、系统字体和语言环境下的测试。

对初中级开发者而言，最实用的习惯是把“看到”与“证明”区分开来。看到卡片圆角，只能证明当前截图有圆角；看到 .borderRadius(20)，才能说明该值来自代码。看到“高速通道已就绪”，只能证明文案出现过；看到真实接口返回、对端日志或抓包，才可能讨论通道是否就绪。代码审阅中每多做一次这种区分，后续说明文档就少一分夸大。

当前页面的色彩还承担了有限但明确的状态表达：绿色与“已连接”绑定，灰色与“可发现”绑定，红色按钮用于“断开”，发送按钮在禁用时呈现系统的禁用外观。红色在这里不等同于错误，只是提示下一次点击会结束当前的本地连接状态。若以后增加真正的失败状态，不能简单复用“断开”按钮的红色就宣称错误已被清晰区分；还需要单独的文字、状态模型和测试场景。

16. 发布前的事实核对清单

这类文章在发布前，建议逐句检查功能动词。凡是出现“发现”“连接”“传输”“同步”“组网”一类词，都要回到入口代码确认其后是否存在对应实现。在这个页面中，能够使用的动词是“展示”“模拟”“切换”“禁用”“启用”“自增”“显示”；不应把它写成“扫描到设备”“已建立真实会话”“发送到平板”“完成跨端同步”。这种措辞差别并非吹毛求疵，它决定读者是否会被文章误导。

初始图、操作图和代码图分别用于核对状态初值、第一次点击后的结果以及源码结构；最终判断仍以 Index.ets 和实际运行结果为准。

最后检查范围。本文分析的是 Index.ets 所呈现的页面，入口配置和截图仅用于验证它能够被启动和展示。未被入口引用的旧组件文件、构建缓存和打包产物都不应扩展为当前功能描述。文章也没有修改应用代码，因此所有关于插值问题、无滚动容器、固定设备名的说明都是“当前版本观察”，不是已经修复的结果。

完成这些核对后，读者会获得一篇可以独立阅读的页面解析：知道工程怎样进入页面，知道首屏有哪几块内容，知道点击后哪几个字段变化，知道发送按钮的真正条件和计数文本为什么不变，也知道“SoftBus”在这里是演示主题而不是已接入的通信能力。对一个小示例而言，准确比堆砌术语更有价值；这也是把它用于学习 ArkUI 时最值得保留的部分。

阅读结束后，不妨自己再做一次逆向核验：先遮住文章，只看 Index.ets，列出所有 @State、所有 onClick 和所有条件表达式；再回到文章，确认每一个结论都能对应到其中一处。这样的阅读方法既能防止被页面题材带偏，也能逐步建立从源码、状态到界面结果的判断能力。对于后续更复杂的 ArkTS 页面，这个习惯同样适用。

在本页中，连接按钮只改变 connected 和 channel，发送按钮只有连接后才可用，点击发送会增加 packets。这三条关系构成了整个交互闭环，复现时应逐条观察和记录即可完成检查。可以。