任务视图切换入口应放在任务集合页的固定工具条上，与筛选、分组同区，用同一组视图标签承载看板、列表、日历三种呈现。切换时把筛选条件、分组字段、排序规则和当前定位对象写入URL或视图状态，让三种视图读取同一份查询结果。入口只负责换呈现方式，不负责换数据范围，用户切过去看到的仍是同一批任务，只是排列方式变了。ONES 的任务看板可作为这类多视图呈现中的看板形态之一，具体视图组合与状态延续能力以实际产品配置为准。
要点总览（TL;DR）
- 视图切换入口固定在任务集合页工具条，与筛选、分组同区，用分段控件或标签页一次展示看板、列表、日历三个选项，当前视图保持明确选中态。
- 切换时把筛选条件、分组字段、排序规则和当前定位对象写入URL或视图状态，三种视图读取同一份查询结果，入口只换呈现方式、不换数据范围。
- 分组字段需跨视图映射：看板中作为列、列表中作为分组行、日历中作为颜色或标签；排序规则要与日历时间轴对应，避免用户误以为数据变了。
- 定位延续采用任务ID加各视图滚动位置两层策略，切回原视图能回到原任务；移动端把视图选项折叠为下拉选择，保留当前视图名称。
- 上线前按任务数量一致、筛选分组保持、URL可还原、空状态一致、定位返回可用逐项验收，阻断项全部通过后再开放入口。
切换入口放在哪：位置、形态与命名
入口的落位决定了用户能否形成稳定预期。把视图切换控件固定在任务集合页的工具条上，与筛选、分组、排序处于同一水平区域，用户在调整查询条件时视线不需要来回跳转。工具条随页面滚动保持可见，长列表浏览到中途也能直接切换视图。
控件形态优先选择分段控件或标签页。分段控件把看板、列表、日历三个选项并排展示，当前视图高亮，用户一眼看到全部可选呈现方式，点击一次完成切换。标签页适合选项较多或需要与页面其他标签共存的场景，但同样要保证三个视图选项一次可见，避免收进“更多”菜单。选项数量固定为三种时，分段控件在点击成本和可见性上更直接。
命名使用视图名而非数据名。“看板”“列表”“日历”描述的是呈现方式，用户理解成本低；“按状态分组”“按负责人分组”描述的是数据组织方式，属于分组控件的职责。两类控件放在同一工具条时，命名要能区分：视图标签回答“怎么看”，分组控件回答“按什么分”。当前视图必须有明确选中态，用底色、字重或下划线区分，不能只靠悬停效果。
移动端与窄屏需要折叠处理。屏幕宽度不足时，把三个视图标签收进一个下拉选择器，触发器上显示当前视图名称和图标，展开后列出全部选项。折叠后仍要保留选中态，用户随时知道自己在哪个视图。下拉选择器的位置与桌面端工具条保持一致，放在筛选入口旁边，避免移动端出现两套操作逻辑。
切换后如何延续筛选、分组与定位
上下文丢失通常发生在三个环节：筛选条件被重置、分组字段在新视图里失效、用户找不到刚才看的那条任务。解决办法是把这些状态从视图组件中抽出来，作为共享查询的一部分统一管理。
筛选条件是共享查询的核心。三种视图读取同一份查询结果，筛选条件在切换时原样传递。实现上把筛选条件序列化为查询对象，视图切换只更换渲染组件，不重新发起不同条件的请求。用户在看板里筛出“本周到期且负责人为张三”的任务，切到列表和日历看到的仍是这批任务。
分组字段需要跨视图映射。同一个分组字段在不同视图里有不同的视觉载体：看板中作为列，列表中可以呈现为分组行或分组表头，日历中可以作为颜色标识或卡片上的标签。映射规则要在设计阶段定清楚，例如“按状态分组”在看板中形成待处理、进行中、已完成三列，在列表中形成三个分组段，在日历中用三种颜色区分任务卡片。映射不一致会让用户误以为数据变了。
排序规则与日历时间轴存在对应关系。列表按截止日期升序排列时，日历视图自然按日期落位，两者口径一致；列表按优先级排序时，日历仍按日期落位，但卡片上要显示优先级标识，让排序信息不丢失。设计时明确哪些排序字段在日历中有视觉表达，哪些只影响列表和看板的顺序。
定位策略分两层。当前选中任务用任务ID记录，切换视图后在该视图中高亮或滚动到该任务；滚动位置按视图分别记忆，切回原视图时还原到离开时的位置。两层策略可以同时使用：用户从看板点开某张卡片再切到列表，列表定位到对应任务行；用户没有选中任务时，切回看板还原之前的滚动位置。
状态写入URL参数，让刷新和分享都能还原。筛选条件、分组字段、排序规则、当前视图和选中任务ID编码进URL，用户复制链接发给同事，对方打开看到的是同一批任务、同一视图和同一位置。URL参数同时便于排查问题，用户反馈“切换后数据不对”时，链接本身就能说明当时的查询状态。
操作步骤：从查询到三视图的落地流程
把上面的规则落成可执行步骤，每一步都有明确的输入、动作、输出和完成标志，便于设计和开发对齐。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一步：定义共享查询对象 | 任务字段清单、筛选维度、分组字段、排序字段 | 确定哪些字段参与筛选、分组和排序，定义查询对象的数据结构 | 共享查询对象定义文档 | 三种视图能基于同一对象取数，字段口径无歧义 |
| 第二步：实现视图容器与切换控件 | 入口落位方案、控件形态规范 | 在工具条放置分段控件或标签页，建立视图容器承载三种渲染组件 | 可切换的视图容器 | 三个选项一次可见，选中态清晰，切换无整页刷新 |
| 第三步：建立分组与排序的跨视图映射 | 分组字段、排序规则、各视图视觉规范 | 按映射规则实现看板列、列表分组行、日历颜色与标签 | 映射规则实现与对照说明 | 同一分组字段在三种视图中表达一致，排序口径可追溯 |
| 第四步：处理定位与返回 | 选中任务ID、各视图滚动位置 | 记录定位状态，切换时还原选中任务与滚动位置，写入URL | 定位与URL同步逻辑 | 切回原视图能回到原任务，分享链接可还原状态 |
四步之间存在依赖：共享查询对象没定清楚，映射规则就无从谈起；映射规则未实现，定位还原也验证不了。建议按顺序推进，每步完成后做一次小范围走查，再进入下一步。第一步的产出物是后续开发和测试的共同依据，团队负责人应参与确认分组与排序口径。
角色分工与各自交付物
视图切换入口涉及界面规范、状态管理、业务口径和验收判断，需要四类角色配合。分工的关键是让规则定义和实现验证分开，避免开发按自己的理解定口径。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 产品/设计 | 定义视图语义、入口位置、控件形态与命名规范，明确三种视图各自回答什么问题 | 入口落位说明、控件规范、视图语义说明 |
| 前端 | 实现视图容器、状态管理与URL同步，保证切换不丢筛选、分组和定位 | 可运行的切换入口、状态同步逻辑、URL参数说明 |
| 团队负责人 | 确认分组字段与排序口径符合团队日常执行跟踪习惯 | 分组与排序口径确认记录 |
| 测试 | 按验收清单检查跨视图一致性，覆盖空结果、异常和定位返回场景 | 跨视图一致性验收报告 |
产品/设计的交付物要在开发启动前完成评审，前端据此实现，测试据此编写用例。团队负责人的确认不必等到开发结束，分组与排序口径在第一步定义共享查询对象时就应参与。测试的验收报告是上线前的最后一道关口，发现不一致时回到对应步骤修正，而不是在视图层打补丁。
在 ONES 中承载这类管理动作时，任务看板可作为团队日常执行跟踪的呈现方式之一，配合统一的查询与分组设置，让不同角色看到同一批任务的同一组织方式。具体支持哪些视图形态和状态延续范围，以实际产品配置和官方说明为准。
示例：同一批任务在看板、列表、日历间的切换
以下为演示情景，用于说明切换前后的一致性，不对应真实团队数据。
设定筛选条件为“迭代为当前迭代、负责人属于前端组”，分组字段为“状态”，排序规则为“截止日期升序”。共享查询返回12条任务。
看板视图下，12条任务分布在待处理、进行中、已完成三列，每列卡片按截止日期从上到下排列。用户点开“登录页适配”这张卡片查看详情，关闭后卡片保持选中高亮。
切到列表视图，页面显示三个分组段，段内任务按截止日期升序排列，“登录页适配”所在行高亮并滚动到可视区域。任务总数仍为12条，分组名称与看板列名一致。
切到日历视图，任务按截止日期落到对应日期格，“登录页适配”落在周四的格子里，卡片颜色对应“进行中”状态。当天有多条任务时，格子内显示任务数量，点开可看到列表。排序规则在这里体现为同日任务的排列顺序。
切回看板视图，页面定位到“登录页适配”所在列和位置，选中态保留。用户不需要重新筛选，也不需要滚动寻找。整个过程中筛选条件、分组字段和排序规则没有变化，变化的只是任务的排列方式。
完成检查：上线前逐项核对
验收按可判断的条目逐项核对，每条给出通过标准，任一条不通过即视为阻断项，修正后重新验收。
| 检查项 | 通过标准 | 阻断级别 |
|---|---|---|
| 三种视图任务数量一致 | 同一查询条件下，看板、列表、日历显示的任务总数相同，无遗漏或重复 | 阻断 |
| 筛选与分组切换后保持 | 切换视图后筛选条件不变，分组字段在三种视图中表达一致 | 阻断 |
| URL可分享并还原状态 | 复制链接在新窗口打开，视图、筛选、分组、排序和选中任务与分享时一致 | 阻断 |
| 空结果与异常提示一致 | 无匹配任务时三种视图给出相同口径的空状态提示，加载失败提示不因视图不同而矛盾 | 阻断 |
| 定位与返回可用 | 选中任务后切换视图能定位到该任务，切回原视图还原滚动位置 | 阻断 |
| 移动端折叠可用 | 窄屏下视图选项折叠为下拉选择，当前视图名称可见，切换行为与桌面端一致 | 非阻断，可排期修正 |
验收时建议用同一组测试数据跑完整流程：先在看板中筛选并选中任务，依次切到列表和日历核对数量与分组，再切回看板确认定位，最后复制URL在新窗口验证还原。空结果场景单独构造一次，确认三种视图的提示文案和操作引导一致。全部阻断项通过后，入口方可上线。
常见问题
筛选条件很多时，全部写进URL会不会太长，应该怎么取舍？
URL长度受浏览器和服务端限制，筛选条件多时不必把所有参数都平铺进去。常见做法是只把用户可见、可分享的核心状态写入URL，例如当前视图、分组字段、排序规则和主要筛选维度；过于细碎的临时筛选可以放在会话状态里，刷新时提示用户恢复。
取舍的判断标准是分享场景：同事打开链接最需要看到的是同一批任务和同一视图，次要筛选条件缺失时页面仍能正常呈现。写入URL的参数建议使用简短键名并做编码，避免中文和特殊字符直接暴露。
三种视图的任务数量对不上，通常是什么原因？
数量不一致多数来自取数口径不统一，而不是视图本身的问题。常见原因有三类：各视图分别发起请求，筛选条件在某一侧没有完整传递；分组字段在某个视图中被当作过滤条件使用，导致部分任务被隐藏；日历视图按日期落位时，没有截止日期的任务被排除在外。
排查时先固定一组筛选条件，分别查看三种视图的请求参数是否一致，再检查日历视图对无日期任务的处理规则。设计阶段就应明确无日期任务在日历中的归属，例如放入单独的“未排期”区域，而不是直接丢弃。
用户在看板里拖动卡片改了状态，切到列表后分组没更新怎么办？
这属于状态变更后的同步问题。拖动卡片修改的是任务数据，列表视图的分组行依赖同一份数据重新计算。如果列表没有刷新，通常是视图容器缓存了旧结果，或者数据变更后没有触发查询重算。
处理方式是在数据变更成功后让共享查询失效并重新取数，三种视图都从同一份最新结果渲染。同时注意保留用户当前的定位，避免刷新后跳回顶部。验收时可以专门构造一次拖动改状态的场景，切到列表和日历核对分组与颜色是否同步变化。
团队规模小、视图使用频率不高，是否值得做完整的URL状态同步？
URL状态同步的价值在分享和排查，与团队规模关系不大。人数少的团队如果经常把任务链接发给同事确认，或者需要刷新页面后继续原来的查看状态，这项投入就有直接回报。
如果团队主要在单一视图内工作、很少跨视图切换，可以先实现视图与筛选的URL同步，定位还原和滚动位置记忆放到后续迭代。判断依据是实际使用中是否出现“刷新后要重新筛选”“发出去的链接对方看到的不一样”这类反馈，有反馈再补全。
日历视图里同一天任务很多，怎么避免卡片堆叠看不清？
日期格容量有限时，优先保证信息可读而不是全部展开。常见做法是格子内显示前几条任务卡片，超出部分显示“还有N条”的入口，点开后在侧栏或弹层中列出当天全部任务。
分组颜色在任务密集时容易混淆，可以配合卡片上的状态标签或负责人缩写辅助识别。排序规则在这里继续生效，同日任务按截止时间或优先级排列，让用户不点开也能判断先处理哪条。设计时把这一规则写进映射说明，避免不同视图对同日任务的顺序理解不一致。
