月视图落地方案：研发团队开展日历视图的实操方法案例解析

研发团队做月视图，最容易低估的不是日期算法，而是“同一天该显示什么、点了以后发生什么、跨时区时算哪一天”这三类决定。只把日期格画出来，页面可能很快完成；但如果事件拥挤、月份切换后筛选状态丢失，或者前后端对全天任务的归属日期理解不同，月视图就会在联调和验收阶段反复返工。我的判断是：月视图不是一个网格组件，而是一组需要产品、设计和研发共同定下来的业务规则。

月视图落地方案：研发团队开展日历视图的实操方法案例解析

一、先讲结论：月视图的成败，取决于规则是否先于代码

1. 先把“日历”拆成四个交付对象

团队讨论月视图时，常把任务概括成“做一个日历页面”。这个说法太宽，容易让每个人默认不同的交付范围。对研发落地更有效的拆法，是把它拆成四个对象：日期网格、业务事件、用户交互、验证规则。网格回答“有哪些日期格”，事件回答“格子里放什么”，交互回答“用户能做什么”，验证规则则回答“怎么判断它做对了”。

这四个对象的依赖顺序不能颠倒。周起始日、跨月日期、事件时间边界等规则尚未确定时，直接开始写组件，后续很可能出现两套日期计算逻辑；产品改了事件展示上限，设计和前端又要重新调整格子高度。先冻结规则，再实现视觉和交互，比先把页面做出来再补规则更能控制返工。

2. 首期先交付可用的月历，不要先交付“全功能日历平台”

展示型月视图与操作型日历不是同一类工作。前者可能只需查看日期、筛选事件和进入详情；后者还会涉及拖动改期、创建、编辑、权限、冲突校验、通知和审计。若首期目标是查看项目排期，却把所有复杂操作都纳入首版，团队会把大量时间花在低频交互上，反而延迟最核心的浏览能力。

我通常建议把首期目标写成一句可以验收的话，例如：“用户能够按月份查看本人负责的任务与里程碑，切换月份后筛选条件保持不变，并能从日期格进入当天任务列表。”这句话比“支持完整日历功能”更明确，因为它限定了用户、动作、状态和结果。

3. 用决策记录代替口头约定

日历规则看起来细碎，却会贯穿前端、服务端、测试和数据分析。把关键决定写进一页规则表，至少记录规则内容、负责人、确认时间、影响范围和待验证项。举例来说，“周起始日为周一”不是一条孤立的视觉说明，它会影响网格生成、日期标题、键盘移动顺序和测试预期。

下表中的时长是团队排期示意，用于展示规则明确与否如何影响实施成本，不是行业基准。实际工作量会随交互复杂度、数据接口和设计系统成熟度变化。

这组估算的价值不在于给项目套用固定工期，而在于提醒负责人：把规则确认纳入排期。如果计划里只有编码和联调，却没有规则评审、边界测试与验收，项目时间表看似短，实际只是把风险推到了后面。

二、背景和真实场景：用户看到的是月份，团队处理的是业务时间

1. 月视图常见于任务排期、项目里程碑和资源安排

以项目排期页面为例，用户希望快速回答三个问题：这个月有哪些关键节点？某一天有哪些待处理任务？任务密集的时间段在哪里？页面不只是把“1日至31日”排成格子，还要把任务、里程碑、负责人筛选和详情入口组织成用户能理解的信息层级。

在中大型团队中，一个日期可能同时关联多个项目、多个负责人和不同状态的工作项。用户看日历时，未必关心底层数据模型，却会立刻感受到三类结果：日期是不是对的、重要事项能不能看见、点击后能不能继续完成工作。研发方案应从这些用户任务出发，而不是从组件库里现成的日历样式出发。

2. 同一个事件可能有多个“日期”

日历最容易出现的认知错位，是团队把所有时间字段都当成同一种日期。任务可能有计划开始时间、截止时间、实际完成时间；里程碑可能有目标日期；全天事项可能没有具体时分。若页面不区分这些含义，团队就会在“这件事显示在哪一天”上产生分歧。

例如，一个截止时间为某日凌晨零点的任务，若服务端将时间戳按 UTC 存储，而用户在其他时区查看，转换后可能落在前一天。全天事件又不一定应该按用户本地时区换算。解决办法不是对所有时间统一加减时差，而是先定义事件的时间语义：它是时间点、时间区间，还是不绑定具体时刻的业务日期。

3. 用项目排期案例先界定首期边界

下面以一个情景示例说明拆解过程，不代表真实客户项目或实测数据。假设某研发团队要在项目空间增加月视图，首期需求是查看任务、里程碑和延期事项；用户可以按负责人过滤，并从日期进入当天列表。团队暂不支持拖拽改期，也不在月历格内直接编辑任务。

这个边界有意把“查看和定位”放在首位。它能验证用户是否需要月视图、用户能否找到关键事项，也避免首期同时承担复杂编辑流程。只有当团队确认用户确实需要在日历里直接修改排期，才值得继续讨论拖动手势、权限校验、冲突处理和操作撤销。

对使用协作平台的团队，日历只是工作流的一种视图。选型时要分别验证平台是否适配组织规模、权限模型、部署要求和数据迁移路径，不要把“有日历入口”直接等同于“满足业务排期”。例如，若团队评估 PingCode，可把中大型组织和 100 人以上团队的协作需求、私有化部署需求以及从 Jira 平滑迁移的要求列入核验清单；这些信息应在采购和技术评审阶段结合当前产品资料、版本能力及迁移范围确认，不能据此推断某个具体月视图功能已经满足所有业务需求。

4. 需求优先级要按用户任务排序，而不是按功能数量排序

首期优先级可以按“没有它，用户是否无法完成核心任务”来判定。日期正确、月份切换、事件定位和空状态属于基础能力；键盘操作、完整读屏语义、跨时区显示等看似边缘的能力，在特定产品和用户群体中也可能是上线门槛。拖拽改期、复杂重复事件、多人排班冲突则通常需要独立评估。

这不是说低优先级能力不重要，而是要明确它们依赖哪些前提。比如拖拽改期必须先有权限校验、保存失败回滚、冲突提示和审计方式；若团队还没定好这些规则，把拖拽列进首期，只是提前承诺了尚未设计完成的复杂度。

三、拆解常见误区：看起来是小功能，返工往往来自边界

1. 误区：月历固定生成六行，问题就解决了

固定六行能让页面高度稳定，但不是所有产品都必须这样做。某些场景需要所有月份的高度一致，避免切月时页面跳动；另一些场景更重视内容空间，允许月份按需要显示四至六周。选择哪种布局，应看页面是否需要稳定高度、是否与其他面板对齐，以及移动端可用面积，而不是直接把“42 个格子”当成标准答案。

实现时还要明确相邻月份日期是否显示、是否可点击、是否参与事件展示。若上月日期以弱化样式出现，但用户点击后又跳转月份，测试和设计必须知道这是预期行为；若点击不可用，也需要清楚的视觉状态，不能只靠开发人员在代码里理解。

2. 误区：每天只显示三条，是可以通用的规则

“最多显示三条”是常见的界面取舍，但三条并非普适答案。格子高度、字体大小、屏幕宽度、事件标题长度和用户是否需要直接扫读，都会改变合适的上限。信息密度低时，固定三条可能浪费空间；信息密度高时，三条也可能占满格子，让日期本身不显眼。

更稳妥的办法是先约定展示策略，再用真实密度或样本数据验证。例如，重要事件优先、普通事件按时间排序；超出可视范围后显示“还有若干项”，点击后进入当天列表。还要明确被隐藏的事件能否通过其他方式发现，不能让颜色、状态和事件数量共同挤在一个小格子里。

3. 误区：接入日期库，时区问题就交给库处理

日期库能提供解析、格式化和计算能力，但它无法替产品决定业务日期。任务截止时间是精确时刻还是日期字段？全天事件是否经过时区转换？跨时区团队看同一会议时，是按创建者时区、项目时区还是当前用户时区展示？这些都是业务语义，不是格式化函数的默认参数。

研发应在接口契约中区分“时间点”和“业务日期”。如果所有内容都以字符串或时间戳混在一起，页面层可能会出现一处按本地时间渲染、另一处按 UTC 截断的情况。建议在联调前用几个明确的边界样例对齐：午夜前后、夏令时转换地区、跨日会议、全天事项和跨月区间。

4. 误区：切换月份只需要替换标题和日期

用户切月后，页面上的月份标题、日期网格、事件数据、选中日期和加载状态必须保持一致。若标题先更新、数据仍是上一月，用户会看到“新月份配旧事件”；如果请求返回顺序与发起顺序相反，快速连续切月还可能让较早的请求覆盖较新的结果。

团队要明确切月时哪些状态延续：负责人筛选通常可以保留；选中日期可以跟随月份调整，也可以清空；滚动位置、展开状态和错误提示则应按产品行为定义。研发实现应处理过期请求或响应竞争，测试也要覆盖快速连续切换，不只验证单次点击。

5. 误区：视觉上可区分，就等于信息可访问

若延期状态仅用红色表示，色觉差异用户或低对比度屏幕上的用户可能无法识别。状态至少应有文本、图标或可读标签中的一种辅助表达。日期格中的可点击区域也要足够清楚，避免用户分不清点击空白处、事件标签和“更多”入口分别会发生什么。

可访问性不是最后补一个图标就算完成。它影响日期标题的读屏顺序、键盘焦点移动、选中状态表达和弹层关闭方式。即使首期不支持所有高级操作，也应把目标平台的基础键盘与辅助技术要求纳入设计评审。

四、专业判断逻辑：用规则、数据和交互链路做设计决策

1. 日期网格先定义输入，再生成输出

不要在多个组件里分别计算日期格。先定义几个输入：目标月份、周起始日、是否显示相邻月份日期、是否固定行数。然后由一个独立的日期计算模块生成完整网格，并为每个日期附上所属月份、是否为当前月、是否为今天、是否可选等状态。显示层只负责呈现这些状态，避免把日期规则散落在样式条件和点击事件中。

举例来说，月视图的首日落在周三时，如果周一是周起始日，首行需要补入本月之前的日期；如果周日起始，补入的日期数就会不同。具体生成几行要服从固定高度策略或内容空间策略。团队不应把不同策略混成一个条件判断，而应明确是哪项产品配置决定输出。

2. 事件数据先标准化，再映射到日期格

接口返回的事件可以有不同来源和含义。建议在进入视图组件前，转换成一致的展示模型，至少包含事件标识、标题、类型、状态、开始边界、结束边界、是否全天、权限状态和详情路由信息。这样，日历网格不必了解每种业务对象的全部字段。

对跨日事件，先确定结束边界是否包含在展示区间内。举例而言，一个从周五到周日的任务究竟跨三个日期显示，还是按截止日只标在周日，取决于用户要观察的是持续占用时间，还是工作项截止时间。两种显示都可能合理，但不能让不同团队各自采用一种。

3. 交互决策要从动作链路反推

日历的点击行为不是孤立事件。用户点击日期后可能进入当天列表；点击任务后可能打开侧边详情；点击溢出入口后可能展开浮层。每个动作都要约定焦点去向、返回方式、筛选条件保留方式和加载失败时的反馈。交互链路越清楚，前端越容易划分组件和状态。

可把月视图的主要链路写成“进入页面，选择月份，筛选事件，定位日期，打开详情，返回日历”。随后逐步检查每一步：页面是否保留当前月份？筛选后日期格如何更新？详情关闭后焦点回到哪里？如果某一步没有明确答案，它就可能成为联调时的隐藏需求。

4. 用数据密度决定展示方式，而不是凭感觉设上限

评估事件呈现时，至少观察三个分布：每天事件数量、事件标题长度、事件类型构成。只看平均值容易掩盖少数高密度日期。建议将样本按日期分组，观察中位数和高分位区间，再挑选“普通日”和“拥挤日”做设计验证。若暂时没有生产数据，可以使用产品访谈整理的代表性样例，并标注为模拟数据。

一个实用原则是：月视图负责发现与定位，不一定负责完整阅读全部事件。若用户需要比较任务详情或连续处理多个事项，点击日期进入列表通常比在格子内压缩更多文字更清楚。月视图的信息上限应由用户任务决定，而不是由“格子还能塞多少内容”决定。

5. 把日期测试做成可重复的边界矩阵

日期测试不应只覆盖“当前月份正常显示”。至少需要覆盖大小月、闰年、跨年、月初落在不同星期、周起始日配置、跨月事件、空数据和无效时间值。时区敏感的业务还应测试用户时区与业务时区不一致、午夜附近的时间点，以及全天事件的显示规则。

测试用例要能被产品、测试和研发共同读懂。例如，不要只写“验证二月日期正确”，而要写清输入年份是否为闰年、周起始日是什么、是否展示相邻月份日期，以及预期网格中的日期范围。用明确的输入和预期结果，才能防止同一条用例被不同人按不同规则解释。

五、案例拆解：一个项目排期月视图如何从需求走到验收

1. 案例范围与前提

以下为便于复用的方案推演。假设一个中大型研发组织希望在项目页面查看任务和里程碑，用户按负责人筛选，并通过日期进入当天列表。现阶段不做拖拽改期，不支持复杂重复事件，也不在日历格内编辑字段。方案目标不是证明某种实现最优，而是展示如何把模糊需求转成可评审、可开发、可测试的决定。

2. 需求评审：先确定用户在月视图里做什么

评审时先把“看项目排期”拆成具体动作：浏览某月节点、识别延期事项、筛选负责人、查看某日任务、打开任务详情。然后逐项确认用户需要的信息。月格不适合塞入任务的所有字段，因此首屏只呈现识别所需的摘要，例如标题、状态提示或负责人标记；详细描述仍留在详情页面。

这一步还要明确“延期”的定义。如果延期按计划截止日与当前日期动态计算，就要约定已完成任务是否仍显示延期；如果延期以服务端状态字段为准，就要确认状态刷新时机。否则前端可能根据日期自行推算，服务端又按业务状态返回，两个系统会对同一任务给出不同结果。

3. 设计评审：把日期格、事件卡片和溢出行为分开定

设计评审可以先选一个普通月份和一个拥挤月份作为样例。普通月份检查日期、标题与筛选状态是否容易扫读；拥挤月份检查事件超出空间后如何提示，以及用户能否快速进入当天完整列表。样例月份只是设计样本，不应被误当作覆盖所有日期边界的完整测试。

接着分别确定日期格和事件卡片的交互区域。日期格空白区域进入当天列表，事件卡片打开对应详情，“还有若干项”打开当天事件列表。不同动作应有明确的按钮语义和焦点反馈，不能把整个格子设成一个大点击区域后，又在内部叠加不清晰的点击目标。

4. 工程评审：约定接口字段和状态流转

工程侧将日期计算、事件适配、接口请求和展示组件分层。日历组件接收当前月份、周起始日、日期格数据和筛选状态；业务适配层负责把不同对象转换成统一事件结构；请求层负责按当前月份和筛选条件加载数据，并处理失败、重试和过期响应。

请求范围也要明确。若事件由开始日期和结束日期决定是否落入目标月份，接口应支持区间查询或由服务端提供按月结果；若前端拉取较大范围再过滤，则要评估数据量和缓存策略。对跨月任务，接口与前端必须采用相同的边界规则，避免一端将结束日视为包含、另一端视为不包含。

5. 验收评审：用可观察结果代替“看起来没问题”

验收时不只检查页面截图，而要验证用户链路和规则结果。切换月份后，标题、网格、数据和筛选状态应同步；连续快速切换时，旧请求不应覆盖新月份；过滤后无事件的日期仍按设计规则显示；点击日期、事件和溢出入口分别进入正确位置。

下表是一组建议验收基准，不是任何特定团队已经达到的实测结果。项目可依据产品要求补充具体数值和平台范围。

6. 用试运行反馈判断是否扩展功能

首期上线后，不要仅用“用户有没有打开过日历”来判断价值。更有解释力的观察包括：用户是否从月视图进入当天列表、哪些筛选条件常用、哪些日期出现高密度事件、用户是否频繁返回上一页重新定位，以及哪些任务仍需要转到其他视图处理。这些观察能说明月视图是否帮助用户完成任务，而不只是页面是否被访问。

如果用户主要用于发现关键节点，月视图可能已经足够；如果用户经常在日期之间比较工作量，可能需要周视图或统计摘要；如果用户希望直接调整任务时间，则应评估专门的排期交互。功能扩展应该由真实使用路径触发，而不是因为同类产品有某个按钮就照搬。

六、不同情况下的行动建议：按团队成熟度和业务复杂度推进

1. 需求尚不清楚：先做规则工作坊，不急着开始编码

如果团队还说不清月视图服务哪些用户、事件按什么日期归属、点击后去哪里，先安排一次短时规则评审。参与者至少包括产品、设计、前端、服务端和测试；涉及跨时区或排班业务时，还应邀请熟悉业务规则的人参与。会议目标不是一次决定所有细节，而是把已确认、待验证和暂缓决策分开记录。

会后交付一页需求边界表、一组关键交互流程和一份日期边界样例。若这些材料仍无法描述用户完成任务的路径，说明需求还不适合进入完整开发；可以先用静态原型做可用性验证，避免在代码层面讨论尚未确定的产品问题。

2. 已有日历组件：优先做业务适配与边界审计

若团队已有通用日历组件，不必立刻重写。先检查它能否配置周起始日、跨月日期、行数策略、键盘交互和日期状态；再检查业务事件映射、时区语义、权限入口和溢出行为。组件能画出日期，不代表它天然适配任务排期、预约或资源管理。

只有当组件的底层假设与业务规则冲突，或者关键能力难以扩展时，才考虑改造或替换。替换之前要列出迁移风险：现有页面依赖的样式、交互、测试和数据格式分别是什么？短期能否通过适配层降低影响？若只因个别视觉差异就重写日期核心逻辑，往往得不偿失。

3. 事件密度高：把月视图定位为索引，而不是详情容器

排期、排班和资源日历通常存在高密度日期。此时应让月视图承担“发现忙碌日期、快速定位事项”的任务，完整阅读和批量处理交给当天列表或其他视图。日期格可以用少量摘要标识事件类型或数量，但不应把所有字段压缩进去。

对于跨日任务，先判断用户需要看到持续占用区间，还是需要看到开始日和截止日。前者适合表现为跨日期条带，后者适合标记关键日期；如果两种信息都重要，可以采用不同的视觉语义，但必须经过设计验证，避免状态颜色和事件类型互相冲突。

4. 面向跨地区团队：把时区和业务日历配置提前

若用户跨地区协作，先明确时间显示采用当前用户时区、项目时区还是组织统一时区。会议这类时间点通常需要精确时刻和时区转换；截止日期或全天事项可能应保持业务日期稳定。不能把同一个转换策略应用于所有事件类型。

还要考虑周起始日和节假日配置是否因地区而异。若产品面向多个国家或地区，相关规则应作为配置或地域化能力评估，而非写死在某个客户端。具体配置范围需要根据产品市场、合规要求和用户设置能力决定。

5. 中大型组织：先治理规则一致性，再扩展视图能力

组织规模变大后，月视图可能被多个团队、项目空间和权限角色共同使用。此时最容易出现的不是单个页面的样式问题，而是同一事件在不同入口的归属规则不一致、权限过滤口径不同、筛选行为各自定义。建议建立统一的日期语义和事件展示约定，再让各业务页面接入。

如果团队通过项目管理平台承载任务与里程碑，评估重点应放在组织权限、数据隔离、部署方式、迁移范围和日历视图与实际工作流的衔接上。对私有化部署或从既有系统迁移有要求的组织，应把部署验证、历史数据映射和迁移后抽样核对单独纳入计划，而不是把它们当成日历页面的附属工作。

七、不同情况下的取舍：首期能力、维护成本和用户价值要一起看

1. 动态高度还是固定高度

固定高度有利于页面布局稳定，也便于与侧边栏或其他面板对齐；缺点是有些月份会出现较多相邻月份日期，或占用比实际需要更大的空间。动态高度能减少空白，却会让切换月份时页面上下变化。若月视图是复杂工作台的一部分，固定高度往往更容易保持整体布局；若页面重点就是日历内容，动态高度可能更紧凑。

不要只在桌面屏幕上做决定。移动端的可视区域有限，固定六周可能压缩事件摘要；动态高度又可能导致页面滚动位置变化。应根据主要终端、信息密度和页面上下文进行取舍，并在测试中检查月份切换时的视觉稳定性。

2. 格内显示更多内容还是更早进入详情

格内展示更多，适合事件标题短、用户需要快速扫读、日期格空间充足的场景；代价是密集日期更拥挤，信息层级容易变乱。摘要加详情入口适合字段复杂、事件数量波动大或需要进一步操作的场景；代价是多一次点击。

团队可以把“用户是否需要在月视图里直接比较多条事件”作为判断依据。如果用户核心任务是找出某天有没有任务，数量和标记可能已经足够；如果用户要在格内比较优先级、负责人和状态，就要警惕月视图是否承担了过多表格职责。

3. 前端缓存还是每次切月重新请求

缓存能减少重复请求，让用户返回已访问月份时更快看到内容，但需要处理数据更新和筛选条件变化。每次请求实现简单，却可能增加等待时间，并在快速切月时形成请求竞争。决策要考虑数据变化频率、访问模式、接口成本和一致性要求。

较稳妥的做法是先确保请求范围正确、加载状态清楚和过期响应可控，再决定是否引入更复杂的缓存。若任务排期频繁变化，过长缓存可能展示旧数据；若内容更新少且用户常往返翻月，适度缓存才可能有价值。没有观测到重复访问或请求耗时问题前，不必为了“优化”而提前增加缓存失效复杂度。

4. 月视图、周视图和时间轴，不必一次全部上线

月视图擅长观察较长时间范围内的分布与节点；周视图更适合看连续几天的安排；时间轴适合观察具体时段、持续占用和冲突。它们解决的问题不同，不能仅按视图数量评估产品完整度。

若用户在月视图里频繁点击某日查看细节，可能只需要当天列表，不一定需要周视图；若用户持续比较一周内的工作负载，周视图可能更有价值；若用户要调整精确时间并识别资源冲突，时间轴可能更适合。优先补齐用户从发现到处理的路径，不要把增加视图数量当成进展。

八、上线前后的执行清单：让方案真正闭环

1. 开发前：确认规则和责任人

• 写清目标用户、核心任务和首期不做的能力。
• 确认周起始日、跨月日期展示、月份行数和日期可点击规则。
• 区分时间点、全天事件、业务日期和跨日区间。
• 定义每天事件的展示策略、排序方式和溢出入口。
• 约定切月后筛选、选中日期和请求状态如何处理。
• 为每项未决规则指定责任人和确认时间，避免问题留在口头沟通里。

2. 开发中：保持职责清楚，控制状态分散

日期网格计算应集中在可单测的模块中；业务对象映射应与展示组件分开；数据请求应清楚处理加载、成功、空结果、失败和过期响应。组件可以有自己的交互状态，但不要让同一份筛选条件同时存在于多个页面状态源中，否则月份切换和返回页面时容易出现不一致。

代码评审时，除了看样式和组件复用，还要检查输入边界、时区转换位置、事件区间端点、空值处理和快速切换月份时的请求行为。对日期逻辑而言，一段短小但有边界测试的实现，通常比多个页面各自复制一份计算逻辑更可靠。

3. 测试中：同时验证日期、数据和操作结果

• 日期测试：大小月、闰年、跨年、不同周起始日和相邻月份日期。
• 事件测试：全天事项、单时点事件、跨日事件、跨月事件和重复数据。
• 状态测试：无数据、加载中、接口失败、重试和权限不足。
• 交互测试：切换月份、回到今天、筛选、日期点击、事件点击和溢出入口。
• 竞态测试：快速连续切月、筛选期间切月、旧请求晚于新请求返回。
• 可访问性测试：键盘焦点、状态文本、读屏顺序和点击目标区分。

4. 上线后：观察路径，不只收集主观反馈

上线后先围绕核心任务观察行为：用户是否切换月份、是否使用筛选、是否从日期进入当天列表、是否打开任务详情、是否在同一日期反复返回。若条件允许，可结合用户访谈解释行为数据，但不能仅凭单一指标推断产品价值。访问量高不一定代表任务完成顺畅，点击量低也可能是用户很快找到目标。

还要保留反馈入口，让用户报告“日期不对”“找不到某项任务”“内容太拥挤”等具体问题。反馈应尽量记录发生的月份、筛选条件、用户时区和事件类型，同时遵循组织的数据与隐私规范。能够复现的问题，才容易转化成明确的修复任务和回归用例。

5. 最后的判断：把月视图当作业务能力，而不是一张页面

月视图真正的工程难点，不是计算某个月有多少天，而是让业务日期、数据边界、视觉表达和用户操作保持同一套解释。只要规则不一致，网格再漂亮也会让人不敢依赖；规则清楚后，组件、接口和测试才能围绕共同的行为实现。

团队下一步可以从一张规则表开始：写下周起始日、事件归属日期、跨日显示、每日溢出、筛选保留和时区策略；再选一个普通月份与一个高密度月份做原型验证，最后用边界矩阵补齐验收。先让用户能够准确发现和理解安排，再决定是否加入拖拽、周视图或复杂排期。这比一开始追求功能齐全，更容易做出可用、可维护、也能继续演进的日历视图。