平行视界购物模式不是简单左右分栏：HarmonyOS 7 连续点详情时栈该怎么走

不才难以繁此生

304人浏览 · 2026-10-01 12:42:15

不才难以繁此生 · 2026-10-01 12:42:15 发布

平行视界购物模式不是简单左右分栏：HarmonyOS 7 连续点详情时栈该怎么走

把列表放左边、详情放右边，只能算双栏布局。平行视界购物模式强调左右推挤和连续浏览：用户在右侧详情继续点推荐项时，已有详情应进入可返回的链条；返回时先退详情链，最后才回到列表。若只保存一个 selectedId，第二次选择会覆盖第一次，返回行为就会和用户预期断开。

连续浏览需要一条详情链路线图

先把边界说明白

关注点	应该怎么理解	容易踩的坑
左侧列表	保持浏览上下文和滚动锚点	详情变化不应重建整个列表
右侧详情	形成连续详情链	推荐项跳转也进入同一栈
全局返回	先弹出右侧详情	右侧为空后再退出当前页面

这张表不是把官方文档换一种说法，而是把接口边界变成能检查的工程条件。适配前先确认当前应用是否命中条件，再决定是否改代码。没有命中的模块不应为了“统一写法”一起重构，命中的模块也不能只改到编译不报错。

案例一：连续打开三个详情后逐级返回

使用独立的 detailStack 保存右侧链，列表滚动位置单独保存。选择列表项时初始化链；在详情中继续选择时追加；返回只弹出一项。纯函数先验证栈行为，再交给 Navigation 或平行视界能力映射。

type ShoppingState = { anchor: string | null; detailStack: string[] };
function openDetail(s: ShoppingState, id: string, fromList: boolean): ShoppingState {
  return { anchor: fromList ? id : s.anchor, detailStack: fromList ? [id] : [...s.detailStack, id] };
}
function backDetail(s: ShoppingState): ShoppingState {
  return { ...s, detailStack: s.detailStack.slice(0, -1) };
}
let s = openDetail({ anchor: null, detailStack: [] }, 'A', true);
s = openDetail(s, 'B', false); s = openDetail(s, 'C', false); s = backDetail(s);
if (s.detailStack.join(',') !== 'A,B' || s.anchor !== 'A') throw new Error('详情链错误');

这一段先验证外围决策。它的价值是让输入和结果可重复，不依赖页面当前碰巧处于什么状态；接入 ArkUI 或系统能力时，再把结果映射成实际节点、路由或接口调用。

案例二：从双栏缩回单栏时保持当前详情

折叠屏合拢或窗口缩小时，右侧当前详情不能消失，也不应把整条链塞进一个路由参数。将双栏状态投影为单栏路径：列表为根，detailStack 依次变成路径；恢复双栏时再根据路径重建右侧链。

function toSinglePath(stack: string[]): string[] { return ['list', ...stack.map(id => 'detail/' + id)]; }
function currentDetail(path: string[]): string | null {
  const item = [...path].reverse().find(x => x.startsWith('detail/'));
  return item ? item.slice(7) : null;
}
const path = toSinglePath(['A','B']);
if (currentDetail(path) !== 'B') throw new Error('窗口切换丢失当前详情');

第二个案例故意覆盖与第一个不同的失败条件。真实工程还应加入快速重复操作、前后台切换、窗口尺寸变化、空数据和恢复路径，避免只验证一次成功流程。

为什么选择这种做法

两套页面各自维护状态会造成收藏、推荐跳转和返回不同步；共享一份可序列化状态，再分别投影为单栏和双栏导航更可靠。验收重点是连续详情、全局返回、合拢展开和进程恢复，而不是只截一张左右布局图。

如果团队准备封装，建议把公开接口保持在“输入事实、输出决策”的层级，不让调用方直接依赖底层节点对象。这样既方便复用，也便于写断言；需要系统能力的部分留在薄薄的适配层，升级时更容易定位。

怎样验证，哪些结论还不能提前说

先把验证分成三层。第一层是纯逻辑：输入、状态转换和边界条件可以在宿主环境运行断言；第二层是 API 26 编译：检查接口签名、系统能力和模型约束；第三层才是目标设备：检查触摸、键鼠、屏幕朗读、横竖屏、窗口缩放和前后台恢复。三层证据不能混在一句“已经跑通”里。

当前示例中的纯 TypeScript 决策函数可以独立测试，用于证明分支没有自相矛盾；涉及 ArkUI 节点、系统手势、跨设备能力和系统服务的片段，仍要使用 API 26 SDK 编译，并在支持该能力的 HarmonyOS 7 设备或云调试设备上验收。这样写不是保守，而是避免把没有发生过的真机结果当成事实。

动态页面还要观察状态变化后的第二次结果：首次进入正确，不代表弹窗关闭、列表更新或窗口缩放后仍然正确。每次状态切换都应重新核对当前节点、焦点目标、返回路径和数据快照，避免旧缓存继续影响新页面。

建议每次留下以下记录：