任务看板有一种很隐蔽的错位：卡片在屏幕上的排列已经变化，点击之后打开的却仍是排序前的位置。它通常不是按钮失灵，而是把“数据顺序”“屏幕顺序”和“被选中的业务对象”混成了一个概念。窗口宽度再发生变化，问题就更难复现。本文用 RankBoard 小看板说明如何拆开这三层关系。下面的数据、日志与配图均为统一设计的演示样例，不代表已在真机或模拟器执行过测试。

一、先确认：GridCol.order 管的是哪种顺序

这次不从折叠状态监听开始，而从一个看似正常的列表开始。RankBoard 有三个任务：R-07「图像处理」，优先级 90、进度 12%、等待中；R-02「语音转写」，优先级 80、进度 68%、处理中；R-11「内容审核」，优先级 60、进度 0%、等待中。选中的任务是 R-02。页面标记当前断点为 sm / 4列，视图顺序为 R-07 → R-02 → R-11。

在大窗口里，产品想让某张任务卡片提前出现，于是开发者给 GridCol 配了 order；另一处点击事件却仍通过 tasks[index] 查找详情。第一眼看，页面布局是对的；换到窄窗口后，视觉顺序与数组顺序一旦不同，同一个 index 就不再对应用户点击的卡片。这个案例并不是宣称 GridCol 会自动改变数组：恰恰相反，它的视觉排序不能被当成数据排序。

华为《响应式栅格布局（GridRow/GridCol）》文档明确给出 GridCol.order 的数字或断点对象配置。较小的 order 会先显示；如果部分子项没有配置 order，未配置项会排在已配置项之前。它用于展示顺序，并没有承诺替应用改变任务数组、点击目标或无障碍阅读顺序。因此后两者必须由业务层自行定义和核验。

二、把“看得见”和“点到谁”拆成两条契约

我给这个看板写了一个很小的约束：唯一可以传给详情页的是稳定的 task.id；排序规则产生的是可见卡片序列，不能反向推导出数据库行号。这个判断比增加一个全局 selectedIndex 更容易维护，因为任务插入、过滤、折叠和异步刷新都可能让索引变化，而业务 ID 不应该变化。

下面是需要警惕的局部写法。它本身是合法的 ArkUI 表达，展示了不同断点的视觉重排；风险出现在外侧继续使用源数组索引定位点击对象时。

// 对照片段：仅定义视觉位置，并未调整业务数组
GridCol({
  span: { sm: 4, md: 4, lg: 4 },
  order: { sm: 3, md: 1, lg: 2 }
}) {
  Text('R-02 语音转写')
}

sm、md、lg 是响应式断点名，不是“手机、平板、折叠屏”三个固定设备类型。官方文档强调，应优先使用应用窗口宽度做断点参考，因为同一设备也可能运行在非全屏窗口中。order 的结果只在布局层成立；如果把顺序变化写成“任务数据已排序”，日志就会误导排查方向。也不能仅凭画面推定读屏焦点会跟着视觉位置走，读屏和键盘遍历需要独立的无障碍检查。

三、先在模型层给出稳定的可见序列

核心做法不是强迫 GridCol.order 承担业务排序，而是对任务数据先进行确定性排序，让常规显示顺序与业务语义尽量一致。相同优先级用 ID 作为第二排序键；不能只依靠网络返回次序，因为后台分页合并和刷新可能改变它。

下面代码解决“相同任务在不同刷新批次中次序飘动”的问题。进度、状态和 ID 是演示约定值，业务项目应由真实状态源更新，而非写死在视图里。

interface TaskItem {
  id: string
  title: string
  priority: number
  progress: number
  status: string
}

const sampleTasks: TaskItem[] = [
  { id: 'R-02', title: '语音转写', priority: 80, progress: 68, status: '处理中' },
  { id: 'R-11', title: '内容审核', priority: 60, progress: 0, status: '等待中' },
  { id: 'R-07', title: '图像处理', priority: 90, progress: 12, status: '等待中' }
]

function sortTasks(source: TaskItem[]): TaskItem[] {
  return source.slice().sort((a: TaskItem, b: TaskItem) =>
    b.priority - a.priority || a.id.localeCompare(b.id))
}

slice() 保留输入数据的原数组，避免其他组件持有同一数组时看到意外的原地变化。priority 是业务字段，不是系统 API；生产环境还应校验它是有限数值，并对被删除的任务清除无效选中态。本例排序后得到 R-07,R-02,R-11，选中态仍保存 R-02，与它出现在第二张卡片的位置无关。

如果产品真的要求某个业务对象在中宽窗口额外置顶，应把这一规则落实到可展示序列或明确定义一个“纯装饰排序”层，不能同时让一处依赖模型位置、另一处依赖屏幕位置。对于键盘焦点或读屏阅读顺序，更稳妥的做法是在交互测试中逐项确认，不能拿 order 的排序截图代替结果。

四、断点变化只改布局，不改业务身份

接下来处理多形态。RankBoard 在 xs 使用 2 列、sm 使用 4 列、md 使用 8 列、lg 使用 12 列；每张卡片对应的 span 分别是 2、4、4、4。也就是说，窄窗口一行一张卡片，中宽窗口可以一行两张，大窗口可一行三张。这里没有引入额外的折叠状态 API，完全把决策交给当前容器宽度。

页面的关键代码如下。ForEach 的 key 始终是任务 ID；点击处理函数接收当前卡片自身的对象，而不是一个浮动索引。

@Entry
@Component
struct QueueOrderPage {
  @State tasks: TaskItem[] = sortTasks(sampleTasks)
  @State selectedId: string = 'R-02'
  @State bpInfo: string = 'sm / 4列'

  build() {
    Column({ space: 12 }) {
      Text('任务队列').fontSize(24)
      Text(`当前断点：${this.bpInfo}`)
      GridRow({
        columns: { xs: 2, sm: 4, md: 8, lg: 12 },
        gutter: 12,
        breakpoints: {
          value: ['320vp', '600vp', '840vp'],
          reference: BreakpointsReference.WindowSize
        }
      }) {
        ForEach(this.tasks, (task: TaskItem) => {
          GridCol({ span: { xs: 2, sm: 4, md: 4, lg: 4 } }) {
            Column({ space: 6 }) {
              Text(`${task.id}  ${task.title}`)
              Text(`${task.status}  ${task.progress}%`)
            }.width('100%').onClick(() => { this.selectedId = task.id })
          }
        }, (task: TaskItem) => task.id)
      }.onBreakpointChange((bp: string) => {
        const cols: number = bp === 'lg' ? 12 : bp === 'md' ? 8 : bp === 'sm' ? 4 : 2
        this.bpInfo = `${bp} / ${cols}列`
      })
    }.width('100%').padding(16)
  }
}

BreakpointsReference.WindowSize 避免把整个物理屏幕宽度错误地当作应用窗口宽度。onBreakpointChange 只更新供人观察的断点文本，不重排任务数据，更不会重置 selectedId。这样尺寸变化与业务动作不会争夺同一个状态字段。真实项目还应补充窗口安全区、长文本截断和字体放大测试；这三个条件不由栅格列数自动保证。

图中的左侧目录、中央代码、右侧模拟器与底部 HiLog 是为说明关系而制作的演示界面，并非真实 DevEco 调试录屏。示意日志约定为 14:40:18 [RankBoard] bp=sm columns=4、order=R-07,R-02,R-11、selected=R-02 progress=68%；它们描述预期检查点，不是性能实测或系统回调证据。图中编辑器保留了布局主干，完整排序函数见前面的模型代码。

五、验收应按对象身份，而不是卡片位置

核查时我更关心四种操作组合。首先在 sm 窄窗口点击第二张卡片，详情必须标记 R-02，进度 68%；其次把窗口扩到 md，重新定位 R-02 并点击，它仍应进入同一对象；然后模拟服务端调整 R-07 的优先级，观察顺序重算是否改变已选中的业务 ID；最后模拟 R-02 被删除，界面应展示“任务已移除”或取消选择，而不是自动把旧第二项当作 R-02。

手机演示图把状态统一在一屏：顶部时间 14:40，sm / 4列，视图顺序 R-07 → R-02 → R-11，R-02 的状态是处理中、进度是 68%。其他任务分别为 12% 和 0%。创建时间 2026-10-11 14:38 只是固定样例字段，不是从真实设备获取的记录。若要验证无障碍，仍需在目标设备上按可聚焦元素逐一读取，记录实际焦点路径；这张图片不能代替测试。

可以把调试日志拆成两个明确标签：viewOrder 表示模型形成的展示序列，selectedId 表示实际点击目标。每次业务重排记录任务 ID 数组和规则版本，断点变化只记录 breakpoint/columns。这样某次点击错位时，能直接区分是模型排序错、事件绑定错，还是视觉层单独重排后的预期不一致。

六、取舍：减少视觉魔术，保留可追踪的语义

GridCol.order 依然有价值：它适合一些只影响展示位置、而且已经仔细定义了交互预期的布局。但任务看板、购物车、审批队列这类以业务对象为中心的界面，我倾向于先建立稳定的可见数据序列，再用 span 处理不同宽度下的卡片数量。视觉位置和数据 ID 越接近，后续测试、埋点、焦点管理的复杂度越低。

当前实现没有覆盖服务端实时推送的冲突合并，也没有声称不同系统版本下屏幕阅读器必然采用某一种顺序。需要上线时，应补真实设备的 xs/sm/md/lg 宽度矩阵、不同字体大小、键盘与读屏遍历、任务移除和高频更新用例。这里可以确定的是技术边界：栅格负责排版，业务模型负责排序，点击必须绑定稳定身份。 这比依赖某一张“排版正确”的截图更可靠。

参考资料：华为开发者官方《响应式栅格布局（GridRow/GridCol）》，2026-09-08 更新：
https://developer.huawei.com/consumer/en/doc/harmonyos-guides/arkts-layout-development-grid-layout