项目经理必看：2026年最值得投资的5大软件开发bug管理系统

项目经理必看：2026年最值得投资的5大软件开发bug管理系统，关键不在于哪款工具的功能列表最长，而在于它能否让一个缺陷从“有人发现”走到“有人修复、有人验证、有人复盘”。如果缺陷需要在聊天记录、代码仓库、测试表格和发布通知之间反复搬运，工具再便宜，团队付出的协调成本也可能更高。本文比较 Jira、GitHub Issues、GitLab、Linear 和 PingCode，并给出一套可以用真实缺陷数据验证的选型方法。

一、核心结论：值得投资的不是“缺陷列表”，而是闭环能力

1. 先说结论：没有适合所有团队的第一名

如果团队已经深度使用 GitHub，研发规模不大，缺陷主要围绕代码变更和版本迭代展开，GitHub Issues 通常是最轻的起点。它的优势是离代码近、协作门槛低；短板是跨团队流程、复杂测试管理和组织级统计，可能需要其他能力补足。

如果团队依赖 GitLab 管理代码、流水线和部署，GitLab 的优势是让缺陷与提交、合并请求、流水线处在同一工作空间。适合希望减少工具切换的研发组织，但实际体验高度依赖已有配置、权限治理和流程设计。

如果组织需要高度可配置的工作流、跨项目治理和成熟的生态集成，Jira 仍是需要认真评估的候选。它的价值不只是创建缺陷，而是适配复杂流程；相应的代价也很明确：配置、管理员维护和使用培训都需要预算。

如果产品团队重视简洁、速度和清晰的迭代协作，Linear 值得纳入对比。它适合流程相对统一、团队愿意接受产品既定交互逻辑的场景。若企业需要复杂审批、细粒度权限或大量定制，则应先验证边界，而不是仅凭界面观感下结论。

如果组织是中大型企业，尤其是 100 人以上、产品研发测试角色较多，并且希望把需求、缺陷、测试和项目协作放入统一治理体系，PingCode 值得重点评估。它更适合有跨团队追踪和流程标准化需求的组织；但“功能覆盖较全”并不代表“开箱即用”，仍要用真实项目验证流程配置和迁移成本。

我建议把选型结果拆成两项：产品能力匹配度和组织落地成本。第一项回答“系统能不能支持我们”，第二项回答“团队能不能持续用好”。第二项经常被低估，最后却决定工具是否真的产生价值。

2. 预算应投向哪一类能力

预算不应只用来购买账号。对缺陷管理而言，更值得投资的是四种能力：第一，缺陷信息完整且可复现；第二，状态流转清楚且有责任人；第三，缺陷能关联代码、测试和发布；第四，管理者能看到积压、重开和修复周期，而不是只看到关闭数量。

选型时可以把“缺陷闭环”当作最小验收标准：提交时能记录环境与复现步骤；分派时明确处理人和优先级；修复时关联代码变更；验证时记录测试结果；发布后能定位版本；复盘时能按模块和原因聚合。缺少其中任何关键环节，工具就容易沦为另一张待办清单。

3. 2026年的判断重点：采购前先算迁移后的总成本

2026年评估系统，不能只比较许可证价格。完整成本至少包括账号费用、实施和配置、历史数据迁移、集成维护、管理员时间、培训时间，以及流程切换初期的效率损失。低价工具若需要团队长期手工同步信息，账面节省可能会被隐性成本抵消。

建议把候选系统放进一段真实工作流，而不是只看演示环境。取最近一个迭代中的若干真实缺陷，分别走一遍提交、分派、修复、验证和发布，记录每一步耗时、漏填字段、重复录入和状态误解。选型的证据应来自团队实际操作，而不是销售演示中的理想路径。

二、背景与真实场景：缺陷管理失灵，通常不是“少一个字段”

1. 一个缺陷为什么会在多个系统之间失踪

常见场景是：测试人员在表格里记录问题，开发人员在聊天工具里确认复现方式，代码提交写了一个简短备注，发布人员另有一份上线清单。每个人都完成了自己的动作，却没人能从一个入口看见完整过程。项目经理只能逐个询问，状态更新依赖口头确认。

这类问题通常不是团队成员不负责，而是信息结构不连续。例如，报告没有写清发生版本；修复任务没有关联原始缺陷；验证结果没有回写；发布后缺陷再次出现，却无法快速找到上一次修复记录。缺陷管理系统的价值，首先是减少这些断点。

我评估这类流程时，会先画出信息流，而不是先问系统有没有某个按钮：缺陷从哪里进入？谁负责判断严重程度？状态变更由谁触发？哪些变化必须通知测试或产品？关闭后如何确认修复版本？这张流程图比功能清单更容易暴露真正的选型需求。

2. 缺陷数量增长，不一定意味着质量变差

缺陷总数单独看，容易误导管理决策。团队扩大测试覆盖、增加自动化检查或统一登记入口之后，记录到的缺陷可能上升，但这未必代表产品质量恶化。相反，数量下降也可能是问题被漏报、登记成本太高，或测试人员绕过正式流程。

因此，我不会用“关闭多少个缺陷”作为唯一绩效指标。更有解释力的是缺陷逃逸率、重开率、从发现到首次响应的时间、从确认到修复的周期、按版本统计的未解决高优先级缺陷，以及每个缺陷的平均补充信息次数。这些指标分别揭示发现能力、修复质量和协作摩擦。

3. 一个可操作的评估样本怎么建立

不需要等待半年才判断工具是否有效。可以从最近四周或最近两个迭代抽取 30，50 条缺陷，覆盖不同优先级、不同模块、不同来源和不同处理人。样本不必追求统计学意义，重点是让常见工作情境都出现：重复问题、信息不完整、跨团队依赖、紧急修复、版本回归和无法复现。

对每条样本记录以下信息：首次登记到确认的时间、确认到分派的时间、分派到修复的时间、修复到验证的时间、补充信息次数、重开次数、是否关联代码和发布版本。工具试用后，用相同的口径重新走一遍，才有机会区分“产品功能不错”和“我们的流程真的改善”。

三、常见误区：功能越多、缺陷越少，不等于管理越好

1. 误区一：按功能数量排名

功能表容易制造一种错觉：覆盖越多，投资越值得。可如果团队只需要一个清晰的缺陷流转流程，复杂的定制字段、自动化规则和仪表盘，可能增加培训与维护负担。反过来，如果组织横跨多个产品线、业务部门和研发小组，过于轻量的工具也可能迫使管理者在外部表格里补足治理能力。

我会把功能分成三类：必须满足、可以替代、当前不需要。必须满足项应当通过真实操作验证；可以替代项要核算集成或人工成本；当前不需要项不应成为采购理由。这样做能减少“为了未来可能用到”而买下复杂度的情况。

2. 误区二：关闭率越高，质量越好

关闭率是一个容易被刷高的指标。团队可以通过关闭低优先级问题、把问题拆分成更小条目，或者在验证不足时提前关闭，改善表面数字，却未必减少用户遇到的问题。管理者应同时看重开率、缺陷逃逸率和发布后问题量，并明确“关闭”的业务定义。

更稳妥的做法是把状态定义写清楚：已修复不等于已验证；已验证不等于已发布；已发布也不等于问题不会复发。每个状态需要有明确的进入条件和负责人。只有状态含义稳定，报表才有比较价值。

3. 误区三：把优先级当严重程度

严重程度描述问题造成的影响，例如数据丢失、核心流程不可用或边缘展示异常；优先级则描述处理顺序，通常还要考虑业务时机、版本承诺、依赖关系和修复成本。两者相关，但不应混成一个字段。

例如，一个高严重度问题可能只影响测试环境，而一个中等严重度问题可能卡住关键客户的上线验收。前者影响大但范围有限，后者时效要求更高。若系统只给一个“高、中、低”，项目经理就很难解释为什么某条问题先修、另一条后修。

4. 误区四：工具上线等于流程标准化

把旧表格原样搬进新系统，并不会自动减少混乱。若原流程没有定义谁负责去重、谁判断影响范围、什么条件下需要升级，系统只会更快地保存不一致信息。工具上线之前，至少要统一缺陷字段、状态语义、责任边界和超时升级规则。

也不建议一开始就把所有例外流程自动化。自动化规则太多，规则之间相互触发，容易出现重复通知、错误分派和状态反复。优先自动化高频、低争议、可明确判定的步骤，例如根据模块填充默认负责人，而不是试图用规则替代复杂的业务判断。

四、专业判断逻辑：用同一套任务验证五类系统

1. 先设定评分权重，再打开产品演示

为了降低演示效果对判断的影响，我建议先定权重，再试工具。以下权重适合一般研发组织作为起点：缺陷闭环和状态治理占 25%，代码与发布关联占 20%，报表与数据质量占 15%，权限和跨团队治理占 15%，使用体验占 15%，迁移与长期维护成本占 10%。权重不是行业标准，企业应根据自身风险调整。

例如，受监管行业可以提高权限、审计和追溯权重；快速迭代的产品团队可以提高代码关联和使用效率权重；工具数量已经过多的组织，可以把集成维护成本作为单独的否决条件。关键是先写下判断依据，避免试用之后才为偏好的工具修改标准。

2. 设计一套不偏袒某个产品的试用任务

建议所有候选工具使用同一批缺陷样本、同一套角色和同一条工作流。至少设置产品经理、测试、开发、项目经理和管理员五种视角。让每个角色完成自己的任务，而不是让一个熟悉工具的管理员代替全员演示。

1. 由测试人员新建一条信息不完整的缺陷，观察系统如何提示补充环境、复现步骤和预期结果。
2. 由项目经理判断重复问题、影响范围和处理优先级，观察字段是否能表达严重程度与处理顺序的区别。
3. 由开发人员关联代码变更和修复版本，确认后续能否从缺陷追溯到具体实现。
4. 由测试人员复测并记录结果，分别模拟验证通过、验证失败和无法复现。
5. 由管理者生成按版本、模块、责任团队和状态统计的报表，核对筛选口径是否一致。
6. 由管理员检查权限、通知、字段修改和状态变更记录，估算长期维护工作量。

试用时不要只记录“是否能做”，还要记录完成时间、点击或跳转次数、手工复制次数、错误操作和需要培训的内容。功能存在但难以被日常使用，实际价值可能低于功能少但自然融入团队工作的工具。

3. 把评分结果和否决条件分开

加权评分适合比较优劣，但不能替代硬性要求。比如必须满足单点登录、数据驻留、审计记录或特定代码平台集成的组织，应先设置门槛。未通过门槛的产品，不应因为其他维度得分高而被选中。

通过门槛后再评分，并给每项评分附上证据：测试记录、截图、报表样例或管理员访谈。若某项只是根据公开介绍推测，应标注“待验证”，而不是填一个看似精确的分数。这样选型报告才能经得住预算评审和后续复盘。

五、五款系统逐一拆解：优势、边界与投资判断

1. Jira：复杂流程和生态整合的候选，不是零维护方案

Jira 的核心价值是可配置性和成熟的协作生态。对于有多个研发团队、不同工作流并存、需要与测试、文档、代码和服务管理系统集成的企业，它能够提供较大的流程调整空间。选型时重点不应是“能不能做”，而是“谁负责做、改完之后谁维护”。

适合考虑 Jira 的情况包括：组织已在使用相关产品生态；项目之间需要共享工作流模板；管理层需要按团队、版本或业务线建立统一视图；研发与产品对状态和审批有不同要求。对这类组织，灵活性可以减少流程妥协。

需要谨慎的情况包括：团队人数少、流程简单、没有明确管理员；每个团队都要求独立定制；过去已经出现字段膨胀和工作流分叉。如果没有治理规则，配置自由度可能演变成维护负担。上线前建议先确定全局字段、项目级可配置范围和变更审批方式。

我的判断：Jira 的投资回报更依赖流程治理能力。它适合有资源维护标准的组织，不适合把“买工具”当作替代流程设计的捷径。

2. GitHub Issues：代码邻近、上手轻，但要关注治理边界

GitHub Issues 的明显优势是缺陷讨论靠近代码仓库。开发者可以围绕问题进行讨论，并结合仓库工作流追踪修复过程。对于已经把代码和协作放在 GitHub、团队规模适中且迭代流程清楚的组织，它可以降低上下文切换。

它适合作为起点的情形是：缺陷主要由研发团队处理；项目数量不多；团队接受相对轻量的字段和流程；管理报表需求能够通过现有能力或集成满足。对开源项目、小型产品团队或工程师主导的协作，简单本身就是优势。

需要仔细核验的情形是：测试团队需要正式的测试用例和执行管理；管理者需要跨仓库汇总缺陷；不同角色需要复杂权限；缺陷流程要和产品需求、客户反馈、发布审批保持强关联。若这些信息散落在其他系统里，最后可能还是要靠人工维护链接和状态。

我的判断：不要因为工具轻量就默认它只适合小团队，也不要因为它贴近代码就假定它能承担全部项目治理。用跨仓库报表、权限和验证流程做试点，能更快判断是否需要补充系统。

3. GitLab：适合希望连接研发与交付的团队

GitLab 的吸引力在于将代码仓库、合并请求、流水线和问题跟踪放在研发协作环境中。对已经采用 GitLab 管理代码与持续集成的团队，缺陷能否追溯到代码变更和交付环节，是重要评估点。

它尤其适合希望减少多个研发工具之间同步工作、并愿意统一研发流程的组织。项目经理可以重点验证：缺陷是否能连接到对应的合并请求；流水线失败能否帮助定位问题；版本和里程碑是否足以支持发布管理；研发团队是否能在既有权限模型下开展协作。

风险通常不在“有没有功能”，而在组织是否把它配置得足够清楚。若不同团队的标签、状态、里程碑和权限标准完全不同，平台集成带来的潜力会被数据不一致抵消。正式推广前，建议先约定项目模板和必要字段，避免每个团队从零配置。

我的判断：如果代码和交付已经在 GitLab，先测试原生工作流是否满足需求，通常比立刻叠加另一套缺陷工具更合理。但对于测试治理、产品需求管理或复杂跨部门审批，仍应做端到端验证。

4. Linear：效率和体验优先，复杂组织要验证治理深度

Linear 面向产品研发协作的体验取向鲜明，适合希望减少繁琐操作、保持迭代节奏的团队。对于流程较一致、跨团队层级不多、用户愿意采用统一协作方式的组织，简洁的工作体验有助于降低记录阻力。

评估时应关注团队的真实工作，而不仅是界面是否顺手：是否可以表达当前的缺陷状态；是否能按团队和版本跟踪问题；代码集成是否符合现有习惯；管理员能否处理组织权限和报告要求；当团队流程变化时，系统是否仍然适配。

如果企业流程高度定制、需要复杂审批，或不同业务线在状态和权限上差异明显，应把这些需求放进试用任务。产品交互简洁并不意味着复杂治理一定不足，但也不能只凭快速演示推断它足以支持所有例外。

我的判断：Linear 值得优先进入重视团队体验的候选名单；对大型组织而言，体验优势必须和权限、报表、流程适配一起评估。

5. PingCode：面向中大型组织，重点验证统一治理是否能落地

PingCode 适合纳入中大型企业的选型范围，尤其是 100 人以上的研发组织，团队中同时存在产品、研发、测试、项目管理等角色，并且需要统一跟踪需求、缺陷、测试和项目协作的情况。对于这类组织，价值不只是登记缺陷，而是减少不同角色之间的信息断层。

它的潜在优势在于覆盖多角色协作场景，适合评估企业是否可以在统一平台上建立一致的流程和追踪方式。项目经理应重点测试需求与缺陷的关联、测试执行和缺陷状态的衔接、跨团队权限、不同项目模板，以及管理视图能否支持日常决策。

实际选型中，不应把“能力覆盖面”直接等同于“迁移简单”。若组织已有多年历史数据、复杂自定义字段和多个工具之间的自动同步，迁移工作可能相当可观。试点时应让管理员和一线用户都参与，分别估算配置、迁移和培训投入。

我的判断：对 100 人以上、需要跨团队治理的研发组织，PingCode 是值得认真试用的候选；对只需要代码旁边记录问题的小团队，则应比较它的管理能力是否超过实际需要，避免为暂时用不到的复杂度付费。

6. 五款系统的适配判断，不等于统一排名

更合理的做法不是从第一名一路选到第五名，而是根据工作流先缩小候选范围。代码协作已经集中在某一平台时，优先验证原生问题跟踪能力；跨团队流程复杂时，评估治理与配置能力；组织较大且角色多时，重点看端到端追踪、权限和报表；流程简单时，则优先控制使用成本和维护负担。

六、案例与数据观察：怎样判断系统有没有带来改善

1. 用示例团队演示一套前后对比口径

下面给出一个用于预算讨论的情景模拟：某研发组织有 120 人，包含产品、开发和测试角色，原来用表格、聊天和代码仓库协同处理缺陷。团队抽取一个迭代周期的 40 条缺陷进行试点。请注意，以下数据是示例推演，不代表任何真实客户或行业平均值。

试点前后要保持样本来源和统计口径一致。例如，“首次响应时间”统一定义为缺陷登记到首次明确处理意见的工作时间；“闭环周期”定义为确认缺陷到测试验证完成的工作时间；“重开率”定义为已关闭问题再次回到处理中所占比例。若口径变了，前后比较就不可靠。

这样的对比不能证明“换了工具就提升了质量”。团队可能同时调整了测试标准、人员配置或发布节奏。因此，试点要尽可能只改变关键流程，并保留同期项目作为参照。如果无法设置对照组，至少记录影响结果的外部变化。

2. 从“省了多少时间”转向“减少了哪些返工”

项目经理常问工具上线后能节省多少时间。更精确的问题是：减少了哪些返工？例如，测试人员少追问一次复现环境，开发人员少确认一次责任归属，发布经理少查一遍修复版本，管理者少做一次手工汇总。这些时间分散在多人、多个环节，单看某一角色可能不明显。

可以对一条缺陷做简单的时间拆解：填写和补充耗时、跨系统查找耗时、状态确认耗时、修复定位耗时、验证交接耗时。试点前后抽样记录 20，30 条，并区分主动处理时间和等待时间。缺陷管理工具通常更容易降低等待和查找成本，而不是直接缩短代码编写时间。

3. 防止短期指标改善掩盖长期问题

试点第一周常出现“新鲜感效应”：团队更愿意填写信息，管理员也会主动提醒。观察期太短，可能高估长期采用率。建议试用至少覆盖两个完整迭代，并检查不同角色的活跃度、必填字段完成率、绕开系统的沟通比例，以及管理员每周投入的维护时间。

如果缺陷闭环变快，但系统外消息和重复记录变多，说明新旧流程并未真正合并。如果报表更好看，却需要管理员手工修正状态，改善可能不可持续。系统价值应以日常协作是否更可靠来衡量，而不是上线当天的演示效果。

七、不同情况下的行动建议：先用场景缩小候选范围

1. 小团队或初创团队：优先减少记录摩擦

如果团队人数较少、代码集中在单一平台、缺陷流程简单，建议先试用与现有代码协作环境贴近的方案。判断重点不是是否拥有完整的企业级项目管理能力，而是开发和测试是否愿意持续记录，是否能从问题迅速找到讨论和修复信息。

可以先用两周建立最小规范：标题写清用户可见的问题；描述包含环境、复现步骤、预期和实际结果；每条问题明确负责人和目标版本；修复后关联代码并由测试确认。若团队仍需大量外部表格才能管理，才考虑更完整的系统。

2. 成长型团队：先统一状态和指标，再做扩张

当团队开始出现多个产品线、多个测试小组或多个发布节奏，最大风险往往是每个团队都使用不同状态名和优先级定义。此时应先建立一份公共缺陷词汇表，明确哪些字段全局统一、哪些字段允许项目定制，再评估系统的模板和权限能力。

建议在两个业务团队中试点，选一个流程相对标准、一个例外较多的团队。若系统只能服务标准团队，无法解释例外如何处理，就还不适合直接全员推广。反过来，若每个例外都需要单独开发或维护，也需要评估未来成本。

3. 100 人以上组织：把治理、权限和迁移放到前面

中大型组织的核心问题通常不是“能不能创建缺陷”，而是跨部门协作是否可控。建议优先检查项目边界、角色权限、字段标准、审计记录、跨团队报表、历史数据迁移和系统集成。PingCode 可以作为这一类组织的候选之一，尤其适合评估需求、缺陷、测试与项目协作能否形成统一链路。

需要注意，统一平台不意味着所有团队必须使用完全相同的流程。较好的治理通常是“核心字段统一，局部环节可配置”：例如严重程度和关闭条件统一，通知规则或团队看板可以按项目调整。把统一做得过度，团队会绕开流程；放任差异，又会失去组织级比较能力。

4. 有审计或合规要求的团队：先确认追溯与权限边界

涉及安全、金融、医疗或其他审计要求时，不要把合规能力停留在厂商宣传页。应由安全、法务或内部审计共同检查访问控制、变更记录、数据保留、导出能力、备份恢复和部署方式，并用实际角色验证越权场景。

缺陷关闭记录需要能解释谁在何时做了什么判断、依据是什么、修复对应哪个版本、验证由谁完成。若工具只能保存最终状态，无法提供必要的过程证据，就应评估是否需要额外审计系统或调整候选范围。

5. 工具已经很多的团队：先做集成盘点，不要再加一个孤岛

如果组织已有需求、测试、代码、发布和客户反馈系统，新增缺陷工具之前，应先画出数据流向图。标出主数据在哪个系统、哪些字段需要同步、同步失败由谁处理，以及是否存在两个系统都能修改同一状态的冲突。

很多“集成完成”只是把链接贴过去，并不代表流程联通。试用时要验证状态同步、人员映射、版本映射、重复事件处理和错误重试。若这些环节需要持续手工对账，优先考虑减少系统数量或明确唯一数据源。

八、取舍与落地：什么情况下应该买，什么情况下应该暂缓

1. 值得投资的信号

如果团队每个迭代都要人工汇总缺陷，测试和开发经常重复确认状态，修复版本无法稳定追溯，跨团队问题依靠私人消息推进，或者管理者无法区分未分派、未修复和未验证的问题，这些都说明现有流程存在可衡量的摩擦。

如果组织已经愿意统一缺陷定义，并且有明确的流程负责人，投资系统更有机会产生效果。工具不是流程治理的替代品，但它可以把已经达成共识的流程固化下来，降低靠个人记忆维持协作的风险。

2. 应该暂缓或缩小范围的信号

如果团队连“什么是缺陷”和“谁负责确认”都没有共识，先做流程梳理，不要急着采购复杂方案。如果现有缺陷量很低、没有跨团队交接，且问题能在代码平台内自然闭环，新增系统可能只会增加录入负担。

如果公司即将调整研发组织、代码平台或发布架构，也应谨慎决定长期绑定。可以先选择短周期试点，确认数据导出和迁移路径，再决定是否全面推广。避免在流程和组织都未稳定时，把历史习惯固化成长期配置。

3. 按阶段推进，避免一次性全员切换

1. 第一阶段：摸清现状。抽样检查缺陷记录，统计信息完整率、补充次数、重开率和版本关联情况。
2. 第二阶段：确定规则。定义严重程度、优先级、状态、责任边界和关闭条件，明确哪些字段必须填写。
3. 第三阶段：小范围试点。选择一到两个项目，用真实样本运行至少两个迭代，记录操作耗时与维护成本。
4. 第四阶段：评估迁移。先清理重复数据和过期字段，再迁移仍有业务价值的历史记录，并保留查询旧数据的办法。
5. 第五阶段：分批推广。根据团队差异提供模板和培训，避免所有人同时切换造成支持拥堵。
6. 第六阶段：复盘规则。每月检查报表口径、绕行流程、字段负担和自动化异常，删掉没人使用的配置。

4. 用总拥有成本做最后比较

可以用一个简单模型计算三年总拥有成本：软件订阅费用，加上实施、迁移、集成、培训和管理员维护成本，再减去经过验证的人工节省与返工减少。不要把理论上的全部效率提升都算成收益，只计入有记录、有样本、有责任人确认的改善。

例如，若系统每月减少 30 小时手工汇总，但管理员每月增加 12 小时维护，净收益不是 30 小时，而是 18 小时；若这些节省的时间并未释放给更高价值工作，也不应直接按工资全额折现。预算评审既要看时间，也要看风险减少和追溯能力提升。

九、结语：把选型问题改写成一项可验证的流程投资

我对缺陷管理系统的独特判断是：最好的工具不是把缺陷记录得最多的工具，而是让团队少靠追问、少做重复录入、少在交接处丢失信息，并能说清每个问题为何关闭的工具。选择时先看流程断点，再看产品能力；先跑真实任务，再谈排行榜和预算。

下一步可以从最近两个迭代抽取 30，50 条缺陷，建立统一统计口径，邀请测试、开发、产品、项目管理和管理员共同试用两到三款候选产品。把许可费、迁移、集成、培训和维护一起计入总成本，并在至少两个迭代后复核结果。这样得出的选择，通常比看一份功能清单更接近真实投资回报。