主从视图保持列表上下文
别名: 主从布局 · 分栏上下文 · 列表加详情 · master-detail
概念解释
主从视图把集合放在一侧，把当前对象的详情放在另一侧，两边同时在场。它的价值不是「看起来像专业工具」，而是列表上下文还在（master-detail context retention）：读完这一条，邻条的名字、状态、排序位置仍在余光里，换下一条不必先退出详情再重新定位列表。单栏「点进去、返回来」把集合藏到了上一页，上下文每次都要重建。
机制
比较和巡检是在集合里移动，不是在单条里定居。详情占用工作记忆去理解这一条，列表则外部保存「我在哪一段、旁边还有谁」。两栏同时可见时，换条是一次选择而不是一次导航：滚动位置、筛选、已读标记都还在。推入全屏详情后，集合变成记忆里的一份残单，返回时还要找回滚动位置、想起刚才看到一半的邻条。主从把导航成本从「进出栈」降成「改选中」，前提是列表栏真的在承担上下文——窄到只剩图标、或详情盖住列表，上下文表面在、实际已经没了。列表栏还要能显示当前选中与邻条的对比，否则它只是一排触发器，不是上下文。
怎么研究
用同一批邮件或记录，比较主从与「进详情再返回」两种结构，做巡检任务（逐条处理并对照邻条状态）和单条深读任务。自变量：列表栏是否可见、列表栏宽度、换条方式（点击邻条 / 返回再进）。因变量：换条时间、返回后的位置丢失、邻条状态误判。巡检任务应在主从上更快；深读任务未必，因为深读不需要邻条。
边界
集合只有一条、或任务几乎从不换条时，主从的列表栏是常驻噪音。触屏竖屏放不下两栏时，硬主从只会把两栏都削到不可用，应退化而不是坚持同时在场。列表栏若不能更新选中态（详情里改了标题，列表还显示旧名），上下文会撒谎。只读预览可以主从；编辑态若详情字段极多，列表栏会被挤成无意义细条，这时编辑应占满，列表退到可召回。
怎么落地
- 巡检、对照、逐条处理的工作台用主从；把列表栏宽度保到识别字段可读、选中态可辨。
- 在详情里改了对象的名称或状态，列表栏对应行要同步，否则上下文是过期的。
- 不要用整页跳转冒充主从：地址变了、列表卸掉了，就不是主从。
- 验证：处理十条中的三条，问邻条此刻的状态。要返回列表才能答，上下文就没被保住。