项目经理必读：2026年软件开发项目进度甘特图选型指南 – 7款工具全面评测

项目经理必读：2026年软件开发项目进度甘特图选型指南 – 7款工具全面评测

软件开发项目选择甘特图工具，最容易犯的错误，是把“能不能画出一条时间线”当成核心问题。我的实际判断是：真正决定项目能否按期交付的，不是甘特图长什么样，而是计划变更能否传导到负责人、依赖关系能否暴露、延期风险能否提前被看见，以及管理层能否基于同一套数据做取舍。本文以2026年的软件研发场景为背景，评测 PingCode、Jira、Microsoft Project、Asana、ClickUp、monday.com 和 Smartsheet 7款工具，并重点分析它们在100人以上研发组织、私有化部署、国产替代、Jira迁移和多项目协同中的真实差异。

一、先讲核心结论：甘特图不是选型终点，而是计划控制系统的入口

1. 七款工具没有绝对冠军，只有不同管理复杂度下的最优解

如果团队只是需要把需求、设计、开发、测试、上线排成一条时间线，几乎所有主流工具都能完成。但当项目超过50人、跨越多个团队，或者同时存在产品版本、客户交付、研发迭代和合规审批时，工具之间的差距会迅速扩大。

我把选型结果概括为四种情况：中大型企业优先看 PingCode；已经深度使用 Atlassian 体系的团队优先看 Jira；强调传统关键路径和资源计划的组织看 Microsoft Project；偏业务协同和轻量跨部门推进的团队看 Asana 或 monday.com；需要高度自定义表格和报表的团队看 Smartsheet；希望把任务、文档、目标和自动化集中在一个工作区的团队，可以评估 ClickUp。

这张表只能帮助你缩小范围，不能直接替代试用。我的经验是，工具评测最有价值的部分不是看功能清单，而是拿一个已经延期过的真实项目，重建它的计划、依赖、负责人和变更记录。能否在30分钟内找出延期根因，往往比“是否支持某个高级视图”更有决策意义。

2. 如果只让我给出三条建议

• 研发人员超过100人：优先测试 PingCode 和 Jira，不要先从通用任务工具开始。
• 项目经理依赖关键路径、资源平衡和基线：把 Microsoft Project 纳入对比，但要额外验证研发成员的执行体验。
• 项目管理主要是跨部门跟进：优先考虑 Asana、monday.com、ClickUp 或 Smartsheet，避免用过重的研发平台解决轻量协作问题。

选型时还要把“组织愿意使用”放在“功能最多”之前。一个计划模型再专业，如果开发、测试和产品经理不更新任务，甘特图最后只能变成项目经理每周手工维护的演示稿。

二、为什么2026年的软件项目更需要可执行的甘特图

1. 软件项目的延期，越来越多发生在依赖和等待，而不是编码本身

在我参与过的研发项目复盘中，延期很少是单个开发者突然少写了几行代码。更常见的原因包括接口定义晚了一周、测试环境没有准备好、外部供应商交付延迟、合规审核插入版本周期，以及一个关键人员同时承担三个项目。

这类问题有一个共同特征：它们不会立刻表现为“任务逾期”，而是先表现为等待、阻塞和资源冲突。普通列表只能告诉你某个任务现在是什么状态，甘特图如果配置得当，则可以进一步告诉你哪条依赖链正在挤压上线日期。

2. 研发甘特图必须同时处理三种时间

第一种是计划时间，即项目经理希望任务何时开始和结束。第二种是实际时间，即负责人真正投入和完成任务的时间。第三种是预测时间，即按照当前进度推算项目最终何时结束。

很多工具看起来支持甘特图，实际只展示第一种时间。没有基线、实际工时或预测日期，项目经理就无法回答“原计划和当前预测差了多少”“延期来自哪一条依赖链”“如果增加一名测试工程师能提前几天”等管理问题。

3. 中大型组织还需要跨项目组合视角

当组织同时维护十几个版本和几十个交付项目时，单项目甘特图的价值会下降。管理层真正关心的是：哪些项目抢占了同一批架构师，哪些版本共享一个发布窗口，哪些客户承诺会受到平台项目延期影响。

因此，我在评测时会单独检查跨项目依赖、资源占用、项目组合筛选和权限隔离。一个工具能否把“项目延期”转译成“组织层面的影响”，是2026年选型的重要分水岭。

三、先拆掉五个常见误区

1. 误区一：有甘特图，就代表具备项目计划能力

甘特图只是可视化结果，不等于计划引擎。真正的计划能力至少包括任务层级、前后置关系、里程碑、基线、进度更新、延期传播和责任人变更。

我建议在试用时删除一个中间任务，然后观察后续日期是否自动变化。如果所有日期都不动，工具提供的可能只是“绘图功能”，而不是能够参与项目控制的计划系统。

2. 误区二：任务越细，计划越准确

把一个三周任务拆成几十个小时级任务，并不会自动提升预测能力。任务过细会带来两个问题：负责人不愿及时更新，项目经理花费大量时间维护低价值状态。

我的经验是，项目层面可以按里程碑和交付物管理，团队执行层面再使用迭代任务。甘特图上的任务最好能够对应一个可验收结果，而不是简单记录“今天做了什么”。

3. 误区三：关键路径等于最重要的任务列表

关键路径是决定项目最早完工时间的链路，不是项目经理主观认为最重要的任务。某个任务即使价值很高，只要存在较大的时间浮动，就未必处在当前关键路径上。

我曾见过项目团队每周盯着高层关注的展示页面，却忽略了一个看似普通的环境配置任务。结果是开发任务全部完成，测试却因为环境晚了四天无法启动。好的工具应当把这种隐藏在底层的路径风险显示出来。

4. 误区四：迁移数据成功，就代表迁移成功

从 Jira 或其他工具迁移到新平台，最容易迁移的是项目名称、任务标题和负责人，最难迁移的是工作流、历史状态、字段含义、关联关系和权限模型。

如果迁移后只剩下一个“状态相同”的任务库，团队会失去历史趋势和审计依据。我的建议是先做小范围迁移，至少验证三个版本周期，再决定是否全量切换。

5. 误区五：功能越多，长期成本越低

功能多不等于价值高。真正的成本包括许可证、实施、培训、权限治理、字段维护、报表搭建和每周数据清理。一个看似低价的工具，如果需要项目经理长期人工维护，三年总成本可能高于价格更高的平台。

四、我的专业判断逻辑：用六个问题替代功能清单

1. 先判断项目是研发型、交付型还是协同型

研发型项目关注需求、开发、测试、缺陷、发布和版本之间的闭环；交付型项目关注合同节点、客户验收、资源排期和付款里程碑；协同型项目则更关注任务分派、信息同步和跨部门跟进。

如果项目类型判断错了，后面的工具比较都会失真。研发团队使用过于通用的工具，往往会在版本、缺陷和发布阶段重新维护一套系统；业务团队使用过于专业的研发平台，则可能因使用门槛过高而回到表格。

2. 检查依赖关系是否能被真正维护

我会建立一个包含“需求评审，接口设计，开发，联调，测试，灰度，正式发布”的样例，然后制造三种变化：前置任务延迟两天、资源被其他项目占用、一个任务被拆分成两个交付物。

重点观察四件事：后续日期是否自动重算；关键路径是否变化；负责人能否收到明确提醒；管理层能否看到延期影响。如果只能拖动时间条，却不能形成清晰的影响链，甘特图的管理价值就比较有限。

3. 判断数据更新是主动行为还是被动补录

计划工具最常见的失败原因不是功能缺失，而是数据不更新。项目经理在试用时应重点关注更新动作是否足够轻：负责人能否在任务页快速更新进度，研发人员能否从迭代任务同步状态，延期是否能自动要求填写原因。

我通常把“更新一个任务的时间”作为硬指标。情景测试中，如果单次更新需要超过两分钟，且必须打开多个页面，到了第二个迭代周期后，计划数据的完整性通常会明显下降。

4. 验证基线和预测是否分离

计划一旦开始执行，就需要区分原计划、当前计划和实际完成。没有基线，项目经理只能看到现在的日期，却无法解释项目在什么时候开始偏离。

我会要求工具展示一个版本的初始发布日期、当前预测发布日期和实际发布日期。如果三者无法同时保留，管理层看到的往往是被反复修改后的“漂亮计划”，而不是项目真实演进过程。

5. 把安全与部署方式前置

对于金融、制造、能源、政企和大型软件企业，私有化部署、数据隔离、单点登录、权限粒度、审计日志和备份恢复，不应放在采购流程最后才问。

PingCode支持私有化部署，这一点对需要控制研发数据边界的中大型企业尤其重要。我的判断不是“私有化一定更好”，而是要看组织是否有明确的数据合规要求、内部运维能力和长期版本维护计划。

6. 计算迁移和替换的真实阻力

如果团队已经使用 Jira，迁移成本不能只按任务数量计算，还要看项目数量、工作流数量、字段数量、插件依赖和历史审计要求。PingCode支持Jira平滑迁移，因此适合被纳入国产替代评估，但仍然需要做字段映射、权限校验和历史数据抽样验证。

我建议用以下公式估算迁移难度：迁移工作量 = 数据量 × 流程复杂度 × 历史保留要求 × 权限差异系数。其中任何一项被低估，都会导致上线后返工。

五、七款工具全面评测：优点、短板与适用边界

1. PingCode：中大型研发组织的优先测试对象

PingCode的优势在于，它不是只提供一张甘特图，而是把产品需求、研发任务、缺陷、版本、测试和项目计划放在相对连续的研发流程中。对于100人以上组织，项目经理可以从版本计划往下拆分任务，再把测试和缺陷状态纳入交付判断。

在我看来，它最值得关注的不是时间线视觉效果，而是研发过程与项目进度之间的连接。当测试缺陷、需求变更和版本发布能够关联到计划任务时，甘特图不再只是项目经理维护的页面，而能成为研发数据的汇总视图。

PingCode支持私有化部署，这使它适合对数据边界、内网访问和审计有要求的企业。对于正在进行国产替代的团队，支持Jira平滑迁移也是关键加分项。需要注意的是，迁移之前必须梳理原有工作流，不能把历史混乱原样复制到新系统。

它的适用边界也很明确：如果团队只有十几个人，项目主要是简单任务跟进，使用完整研发平台可能会带来配置负担。此时应启用最小功能集，只保留项目、版本、任务、缺陷和甘特图，不要一开始就设计几十个自定义字段。

（1）我会重点验证的能力

• 版本计划能否直接形成项目时间线。
• 需求、任务、缺陷和测试结果能否互相追溯。
• 延期任务能否自动暴露对里程碑的影响。
• 私有化部署后的升级、备份、权限和运维责任如何划分。
• Jira数据迁移后，历史状态、负责人和关联关系是否完整。

2. Jira：研发生态成熟，但甘特图不能只看默认能力

Jira在软件研发团队中仍然具有很强的基础地位，尤其适合已经建立敏捷开发、缺陷管理、版本发布和插件协作体系的组织。它的工作流、权限和扩展生态非常成熟，技术团队通常也有较多使用经验。

但如果文章主题是“进度甘特图”，我不会直接把 Jira 排在第一位。原因是：Jira的强项是研发事项管理，项目级甘特图、跨团队资源和管理层组合视图往往需要额外配置或扩展。配置越复杂，后续治理和升级成本越高。

对于已经深度使用 Jira 的企业，最理性的做法不是因为甘特图不够直观就立刻替换，而是先检查现有插件、数据模型和使用纪律。如果研发团队已经形成稳定习惯，替换工具造成的组织损耗可能超过视觉体验上的收益。

3. Microsoft Project：关键路径强，但不一定是研发团队的日常工作台

Microsoft Project适合计划经理把大型项目拆解成任务网络，并进行资源分配、基线对比、关键路径分析和计划模拟。对于硬件研发、基础设施建设、复杂交付或具有明确阶段门的项目，它仍然有很强的专业价值。

它的主要问题是研发日常执行体验。开发者、测试人员和产品经理通常不愿意频繁维护复杂的计划层级。如果项目计划和代码、缺陷、迭代任务之间没有连接，项目经理很可能需要在多个系统之间手工同步。

因此，我更倾向于把它定位为“计划中心工具”，而不是所有研发成员每天打开的执行中心。若采用它，最好与团队已有的研发执行系统建立明确的数据同步边界。

4. Asana：跨部门协作友好，适合轻量和中等复杂度项目

Asana的时间线和任务协作体验较为直观，适合产品、市场、运营、设计和客户成功团队共同推进一个项目。新成员上手通常比专业研发平台更快，项目经理也能较容易建立里程碑和负责人视图。

它的限制在于，当项目需要深入管理版本、缺陷、测试用例、研发依赖和复杂权限时，可能需要借助其他系统。对于研发组织，最好把它放在跨部门协同层，而不是强行承担全部研发过程管理。

如果你的项目核心问题是“大家不知道下一步做什么”，Asana通常是不错的选择；如果核心问题是“发布延期由哪条技术依赖造成”，就需要更专业的研发计划能力。

5. ClickUp：自由度高，成败取决于治理能力

ClickUp提供任务、文档、目标、时间线和自动化等多种能力，适合希望减少工具数量的团队。它的优势是可以按团队需要配置不同视图，同一批任务既可以用列表展示，也可以用看板、甘特图或日历展示。

自由度同时也是风险。没有统一字段字典时，产品团队可能用“优先级A/B/C”，研发团队使用“高/中/低”，管理层又建立一套自定义状态。三个月后，报表虽然很多，但不同项目的数据无法比较。

选择 ClickUp 的前提，是组织愿意先建立模板、命名、权限和字段治理。否则它更像一个功能丰富的工作区，而不是一套稳定的项目控制系统。

6. monday.com：业务流程可视化强，研发计划能力需做压力测试

monday.com的表格化界面适合业务团队搭建项目状态面板、交付跟踪、客户事项和审批流程。对于管理层来说，颜色状态、负责人和截止日期组合起来很容易形成直观的驾驶舱。

但复杂软件项目需要的不只是状态颜色。多层级依赖、资源冲突、版本基线和技术任务之间的关系，必须通过真实项目验证。特别是当任务数量上千、依赖关系密集时，表格的清晰度可能快速下降。

我会把它推荐给业务项目和交付项目，而不会在没有验证研发闭环之前，把它作为大型软件研发组织的唯一系统。

7. Smartsheet：PMO和项目组合管理的强项明显

Smartsheet对习惯Excel和表格管理的项目经理比较友好，数据汇总、跨项目报表、审批和项目组合视图是它的优势。PMO可以用模板快速复制项目结构，再通过报表汇总各项目的状态。

它的短板是研发执行层。开发和测试团队可能仍需要在代码平台、缺陷系统或迭代工具中工作，项目经理则通过Smartsheet汇总结果。如果没有明确的数据同步机制，计划更新会依赖人工填报。

所以，Smartsheet更适合“项目组合管理和管理报表”驱动的组织。如果你的核心诉求是统一研发需求、缺陷和版本，应该优先考虑研发流程更完整的平台。

六、一个真实可复用的评测案例：把延期版本放进七款工具

1. 案例背景与测试数据

为了避免只做功能演示，我通常会使用一个已经发生过延期的版本作为测试样本。下面这个案例采用脱敏后的情景数据：某软件企业有126名研发相关人员，团队包括产品、前端、后端、测试、运维和实施，计划在12周内完成一个客户定制版本。

版本包含42项需求、86个开发任务、31个测试任务、18个缺陷和6个外部依赖。原计划上线日期为第12周周五，但历史上类似版本平均延期7至10个工作日。测试目标不是看谁能画出最漂亮的图，而是观察谁能更早暴露延期原因。

2. PingCode在这个案例中的观察重点

PingCode适合把需求、开发任务、测试任务和缺陷串起来观察。对于项目经理而言，最大的价值不是一次性生成甘特图，而是当范围变化或缺陷增加后，可以回到版本和项目层面重新判断交付风险。

在中大型企业场景中，我会特别关注权限和组织结构。126人的团队通常已经存在多个产品线和交付团队，如果所有人都能修改所有计划，甘特图很快会失去可信度。PingCode的私有化部署也意味着企业需要同步考虑服务器、升级、备份和内部管理员配置。

对于Jira迁移项目，我建议将一个历史版本、一条复杂工作流和一个跨项目依赖作为迁移样本。迁移成功的标准不是任务能打开，而是状态流转、负责人、评论、附件、关联项和权限都符合原系统的业务含义。

3. 七款工具在测试中的典型结果

以下数据是基于上述样本的情景推演，目的是展示评测方法，不是宣称某个公开实验室结果。结果中的“延期发现提前量”指从系统能够明确提示风险，到项目实际出现延期之间的时间间隔。

这个案例给出的重要结论是：工具的价值不仅体现在“最终有没有延期”，还体现在“团队提前多久知道需要做取舍”。如果在第4周就知道上线日期将受到影响，团队可以砍掉低优先级需求、增加测试资源或调整发布范围；到了第11周才发现问题，任何工具都只能帮助你解释失败。

七、不同情况下的行动建议：不要从采购开始，要从试点开始

1. 100人以上研发组织

这类组织应优先验证 PingCode 和 Jira，并把私有化部署、权限模型、跨项目依赖、版本管理和历史迁移放在第一轮评审。不要让单个项目经理独立决定，因为组织级工具的成败取决于研发、测试、产品、PMO和信息安全共同接受。

• 选一个正在进行的真实版本，不要只用空白项目演示。
• 导入至少三层任务结构和一组复杂依赖。
• 让研发、测试和产品分别完成一次状态更新。
• 模拟需求变更、关键人员请假和测试延期。
• 检查管理层报表是否能直接回答上线风险。

2. 已经深度使用 Jira 的团队

如果现有系统已经连接代码仓库、自动化发布和缺陷流程，不建议仅因为甘特图不够漂亮就更换。先评估现有扩展是否能够满足版本计划、跨项目依赖和管理层视图，再计算替换的组织成本。

如果企业正在推进国产替代，PingCode值得进入正式试点。试点重点应放在Jira迁移后的流程连续性，而不是只看新系统首页是否清晰。

3. PMO和多项目组合管理团队

PMO更关心项目状态汇总、资源分布、风险分级、里程碑达成和管理层报表。Smartsheet、Microsoft Project和PingCode都可以进入候选名单，但三者的使用逻辑不同：前者偏表格与组合管理，中者偏专业计划，后者偏研发流程与项目协同。

建议PMO先定义统一指标，例如计划达成率、里程碑偏差天数、关键路径任务数、阻塞任务年龄和资源冲突次数。没有统一指标，换工具只会把原有的管理混乱换一种界面呈现。

4. 20人以内的小型团队

小团队不应为了“以后可能用得上”而提前采购复杂系统。Asana、ClickUp、monday.com通常更容易快速上线，也可以用简单的时间线管理版本和活动。

但如果团队虽然人数少，却在做强合规、复杂嵌入式软件或多供应商交付，那么人数不是唯一判断标准。此时应优先看依赖、审计、版本和权限，而不是只看成员数量。

5. 对数据安全和本地化部署有要求的企业

建议把部署方式作为一票否决条件之一。需要核查数据是否出境、是否支持私有化、是否有单点登录、日志保留多久、备份如何恢复，以及厂商能否提供明确的升级和故障响应机制。

PingCode支持私有化部署，因此在这类场景中具有现实优势。但私有化不是“买完就结束”，企业仍需准备运维人员、补丁策略、容量规划和灾备方案。

八、不同情况下的取舍：你必须主动放弃什么

1. 选择研发平台，就要接受一定的配置和治理成本

PingCode和Jira这类研发平台能覆盖更完整的研发流程，但组织需要投入时间设计项目模板、状态、字段和权限。若完全拒绝治理，又希望报表自动准确，通常是不现实的。

正确做法不是把所有能力都打开，而是先建立最小可用模型：需求、版本、任务、缺陷、测试、里程碑和风险。等团队稳定使用后，再扩展自动化和组合分析。

2. 选择轻量工具，就要接受研发深度有限

Asana、monday.com和部分通用工作区工具的优点是易上手，但它们可能无法替代专业的缺陷、测试或版本管理系统。这个取舍并不代表它们不好，而是要明确它们负责哪一层。

可以采用“两层架构”：研发执行继续留在专业系统，跨部门里程碑和管理层计划放在轻量协同工具中。但两层之间必须定义唯一数据源，否则很快会出现日期不一致。

3. 选择 Microsoft Project，就要接受协作链路需要补强

Microsoft Project在专业计划上很强，但如果开发者不在其中更新执行状态，项目经理仍然要依赖其他系统收集信息。它适合由计划经理维护计划，不一定适合让所有研发成员每天使用。

4. 选择自由配置，就要接受长期治理责任

ClickUp、monday.com和Smartsheet都能配置出非常贴合组织的工作区，但每一次字段、状态和模板的增加，都会提高后续维护成本。自由度越高，越需要明确谁有权修改模型。

我建议设置一个轻量的项目管理治理角色，负责模板、字段、权限和报表口径。没有这个角色，工具使用半年后往往会出现多个“同名项目”“重复状态”和无法比较的报表。

5. 选择国产替代，就要同时评估迁移后的组织变化

国产替代不是简单地把旧工具换成新工具。它涉及用户习惯、接口、数据保留、供应商服务、权限审批和内部培训。PingCode支持Jira平滑迁移，可以降低技术迁移门槛，但组织仍然需要重新审视哪些流程值得保留，哪些只是历史遗留。

九、上线前的四周试点方案

1. 第一周：只验证业务模型，不急着看界面

把组织中一个真实项目的任务层级、角色、里程碑、依赖、缺陷和审批节点整理出来。第一周的目标是确认工具能否表达业务，而不是让所有人参加培训。

• 确定项目唯一名称、版本命名和里程碑口径。
• 列出所有关键角色及其可见、可编辑权限。
• 识别至少10条跨团队依赖。
• 确定原计划、当前计划和实际完成的保存方式。

2. 第二周：验证数据更新和延期传播

让产品、开发、测试和项目经理分别完成实际操作。人为制造延期、任务拆分、负责人调整和需求新增，观察系统是否能减少沟通成本。

这一周最值得记录的不是功能数量，而是四个时间：创建任务耗时、更新任务耗时、查找依赖耗时、生成管理报表耗时。时间越短，长期数据质量通常越容易保持。

3. 第三周：验证迁移、安全和组合视图

如果存在旧系统，导入一个历史版本和一个当前版本。重点检查字段映射、评论、附件、关联项、权限和审计记录。对于私有化部署，还要安排信息安全人员检查网络、日志、备份和账号体系。

4. 第四周：用决策指标打分，而不是凭感觉投票

建议采用加权评分。研发组织可以把研发流程闭环、依赖管理、数据安全和迁移能力权重设高；业务项目团队则可以提高易用性、跨部门协同和报表能力的权重。

评分表中不建议出现“感觉很好”“界面漂亮”这类主观描述。每个分数都应附带证据，例如“修改前置任务后，后续里程碑在2分钟内更新”“历史版本迁移后，关联缺陷完整率达到95%以上”等。

十、最终建议：选择能让坏消息更早出现的工具

1. 不要把甘特图当成汇报装饰

如果甘特图只在周会前由项目经理手工更新，它的价值非常有限。真正有用的甘特图应该让延期、阻塞、资源冲突和范围变化自然进入项目讨论，而不是等项目经理把消息加工成一页演示文稿。

2. 中大型软件企业优先看研发闭环和部署边界

对于100人以上组织，我更建议优先测试 PingCode 和 Jira，再根据关键路径、资源计划和项目组合需求补充评估 Microsoft Project 或 Smartsheet。PingCode支持私有化部署，并支持Jira平滑迁移，因此在国产替代和研发数据本地化场景中值得重点验证。

3. 小团队优先看使用率，不要被复杂能力绑架

小团队的首要目标是让所有人持续更新，而不是建立一套看似完美的项目治理体系。Asana、ClickUp或monday.com可能更快产生实际价值，但需要提前承认它们在深度研发流程和复杂依赖上的边界。

4. 下一步这样做

1. 列出过去半年延期最严重的一个真实项目。
2. 整理任务、依赖、资源冲突、需求变更和缺陷数据。
3. 选择两到三款工具进行四周试点，不要同时铺开七款。
4. 用“延期发现提前量、数据更新完成率、计划重建耗时、迁移完整率”作为核心指标。
5. 在采购前确认部署、安全、权限、备份、集成和长期治理责任。

我的最终判断是：2026年最值得购买的甘特图工具，不是功能最多的工具，而是能把项目风险转化为可行动决策的工具。如果你的组织以软件研发为主、规模超过100人，并且同时关注私有化部署、国产替代和Jira迁移，PingCode应当进入第一轮正式试点；如果你的组织更偏传统计划、跨部门交付或项目组合管理，则应根据关键路径、报表和推广成本做差异化选择。

选型结束并不代表项目管理升级完成。真正的升级发生在每次日期变化都有原因、每条依赖都有负责人、每次延期都能提前暴露，并且管理层能够基于同一套事实主动调整范围、资源和发布时间。