2026年国产首选的项目管理软件推荐：深度测评与选型指南

选国产项目管理软件时，最容易买错的不是“功能少”的产品，而是看起来什么都有、上线后却没人愿意持续更新的产品。做选型时，我不会先问哪款软件排名第一，而会先追问：团队的项目究竟卡在任务分派、进度依赖、跨部门协作，还是预算与资源核算？这篇《2026年国产首选的项目管理软件推荐：深度测评与选型指南》不把缺少可核验依据的搜索结果包装成实测排名，而是把选型拆成可验证的流程，帮助团队按场景缩小候选范围、识别真实成本，并用试点结果作决定。

一、先说结论：首选不是一个名字，而是一组适配条件

1. 给不同团队的快速结论

如果团队只需要明确负责人、截止日期和当前状态，先试轻量协作工具，不要为复杂流程买单。如果项目有任务依赖、里程碑、资源冲突和多项目汇总，就应重点比较计划能力、组合视图和权限治理。如果涉及研发过程，需求、迭代、缺陷、版本与项目状态之间能否形成连贯链路，比单独看一张看板更重要。

对中大型组织而言，工具选择还不只是项目经理的个人偏好。账号治理、组织权限、数据导出、系统集成、审计留痕、部署和运维责任，都可能决定一款产品能不能进入正式采购。此时建议把“功能适用”和“组织可治理”分开评分，不要用功能清单代替企业级适配评估。

我会把“首选”拆成三个问题：能否覆盖当前工作流，团队愿不愿意持续使用，组织能否负担长期维护成本。三项都过关，才是适合自己的候选；任何一项明显不合格，都不该因为产品名气、演示效果或销售承诺而直接进入采购。

2. 本文能给出的推荐边界

现有搜索调研结果没有提供可确认的完整项目管理软件测评正文：候选页面中包括应用下载入口、推广服务页、搜索结果页和备案页面。它们不足以支持产品排名、功能优劣、客户案例、价格或真实体验结论。因此，本文不声称对多款软件做过同条件实测，也不杜撰“第一名”“使用效率提升多少”等结果。

这不意味着选型只能停留在空泛原则。相反，面对证据不足的市场信息，最有用的推荐方式是把候选按使用场景归类，再给出验证办法。对产品能力、版本限制、部署方式和报价，必须以试用环境、正式合同、官方文档或供应商书面答复为准；无法确认的地方，就应明确列作待核实项。

文章后文会以 PingCode 作为中大型组织候选评估的示例名称，但不会把未经验证的功能或效果写成实测结论。它的具体模块、版本能力、部署选项、价格和服务范围，均应由采购方在当前版本中逐项核验。这个处理方式同样适用于其他产品：名称可以帮助建立候选清单，不能替代验收。

3. 一句话选择路径

先确定不能妥协的条件，再让候选产品跑真实项目，最后比较总拥有成本。不要先把功能数量排个序，也不要把“国产首选”理解为所有行业、规模和项目类型共用一个答案。选型结论应当能解释：为什么这款适合这支团队、哪些需求暂时不支持、上线后由谁维护。

二、先识别真实场景：软件要解决的是工作流断点

1. 任务很多，不等于需要复杂项目管理平台

有些团队把“任务太多”当成采购理由，但真正的问题可能只是任务入口分散：有人在群里说，有人记在表格里，还有人只在周会上口头更新。此时，第一阶段需要统一任务记录、责任人、截止时间和状态，而不是先引入复杂的资源池、预算模型与审批层级。

判断团队是否需要更强的项目管理能力，可以观察一个信号：项目负责人能否在十分钟内回答“哪些关键任务正在延期、延期会影响什么、需要谁作决策”。如果每次都要逐个问人、翻聊天记录、重新拼表格，问题不是任务数量，而是状态信息没有形成可追溯的结构。

轻量工具并非低级选择。流程越简单，越应避免过度配置。一个五人团队每周只开一次项目同步会，可能更需要易上手的任务列表与清楚提醒；一个同时管理数十个跨部门项目的组织，则可能需要组合视图、统一权限和管理报表。工具能力要和管理复杂度相匹配。

2. 研发项目要看链路，不只看看板

研发团队常见的失真，是看板上任务状态很整齐，但需求、缺陷、发布版本和项目目标彼此断开。团队看见“进行中”三个字，却不知道它对应哪个版本、依赖什么测试、是否会阻塞其他工作。只比较看板样式，会漏掉工作流能否闭环这个关键问题。

试用时，我建议从一个小而完整的变更开始：新建需求，拆分工作项，标明负责人和依赖，进入迭代，处理缺陷，完成验收，再确认交付物或版本记录。重点不是这条链路是否能被产品演示出来，而是日常使用是否需要重复录入、手工同步状态或绕开系统。

如果团队已有代码托管、测试、文档或即时沟通系统，还要核对连接方式与边界。所谓“支持集成”不能只停留在产品介绍页上的图标，应该验证它能传递哪些字段、是否双向同步、失败后谁能排查、权限如何继承。没有实测前，集成能力只能列为待确认项。

3. 工程与交付项目要验证计划、变更和资源

工程项目、咨询交付和客户实施常常有明确里程碑、外部依赖、现场信息与变更记录。对这些场景来说，单纯展示任务完成率容易产生误导：如果关键路径上的前置环节延期，其他大量普通任务按时完成，也不能说明项目整体健康。

建议选一个正在执行的项目，把计划阶段、交付节点、外部依赖、变更审批和风险升级放进试用流程。观察负责人能否迅速识别前置任务变动的影响范围，管理者能否看见跨项目资源冲突，团队成员能否在现场或移动端更新必要信息。

另一个需要核验的细节是“计划基线”。团队要确认系统能否保留原始计划、记录调整原因，并让管理者看见当前计划与原计划的差异。若每次延期后只覆盖原日期，事后就很难还原项目为什么偏离，也难以积累可复用的估算经验。

4. 企业选型的重点是治理和责任边界

组织规模扩大后，个人创建项目的自由度可能与企业治理要求发生冲突。项目空间由谁开通、人员离职后内容如何处理、外部合作方能看到什么、谁能导出数据、审计记录保留多久，这些看似不如任务看板直观，却会影响长期运营。

对于有本地部署、私有化、数据驻留、账号统一管理或特定合规要求的组织，不要用一句“支持企业级”结束评估。应当让供应商说明具体版本、部署架构、责任分工、备份恢复机制、升级方式、日志范围和需要客户自行承担的资源。

三、常见误区：看起来专业的比较，可能不帮你做决定

1. 把“功能多”误当成“适配度高”

功能列表越长，不代表团队获得的价值越大。每增加一个模块，都可能带来配置、培训、维护和权限设计成本。对于当前流程没有使用条件的功能，短期内是负担而非优势；对于必须靠外部表格补上的能力，即使基础功能很多，也可能不够用。

我更愿意把功能分成三类：必须项、试点验证项、暂不考虑项。必须项直接决定是否淘汰；验证项通过真实流程判断深度；暂不考虑项不进入第一轮评分。这样能避免采购会议中每个人都提出一个“以后可能会用”的功能，最后让方案被边缘需求拖复杂。

2. 把演示环境当成真实使用体验

演示往往由熟悉产品的人操作，数据也经过整理，路径自然顺畅。日常使用却有缺失字段、临时插单、人员调动、依赖变更和权限错误。试点时不能只让产品顾问演示，应让未来真正使用系统的人完成任务，并记录他们在哪一步停下来、找不到入口或选择回到旧工具。

建议至少安排项目负责人、执行成员、管理者和系统管理员参与。四种角色关注点不同：成员在意录入负担，负责人在意进度和风险，管理者在意跨项目信息，管理员在意权限与维护。只让采购者或项目经理试用，很容易低估推广阻力。

3. 把低订阅价当成低总成本

采购报价只是成本的一部分。实施配置、历史数据迁移、培训、定制开发、接口维护、环境资源、运维和值守，都可能进入实际支出。对长期使用的系统来说，第一年费用低不代表三年成本低；每次版本升级都需要重新定制，也会形成隐性负担。

比较价格时应统一口径：相同用户数、相同部署方式、相同模块范围、相近服务级别和相同统计周期。若供应商报价包含实施服务，另一家只报软件许可，两者不能直接比较。所有未明确的收费条件都要书面确认，尤其是账号扩容、存储、接口、培训和续保。

4. 把“国产”当作无需核查的安全结论

国产属性与部署能力、数据控制权、研发主体、供应链适配不是同一个概念。采购方应先定义自己所说的“国产”：关注的是产品研发主体、软件著作权、服务团队、部署位置、核心组件，还是信创环境适配？定义不清，评估表里的“国产化”就容易变成无法验收的标签。

安全与合规能力也不应靠宣传语判断。要核对适用版本、认证主体、覆盖范围、有效期及其与实际部署环境的关系。涉及重要数据时，建议由组织安全或法务团队直接审阅合同和技术说明，不把营销材料当作最终依据。

5. 把公开评分、下载量或搜索热度当产品实测

应用分发页的评分和下载量，统计口径、时间范围、用户构成与本文所说的企业项目管理能力并不相同。搜索结果页出现某个产品，也不能证明其排名代表市场份额或专业测评。引用这些指标之前，要先确认它们测量的究竟是什么，以及能否回答当前选型问题。

这次调研中的四条候选结果没有提供可拆解的完整项目管理软件评测正文。因此，本文不从这些页面推导产品表现，也不把它们描述为竞品常见写法。对内容读者来说，这个限制本身很重要：没有可复核证据时，负责任的做法是说明信息不足，而不是用确定语气填补空白。

四、专业判断逻辑：用一套能复核的标准比较候选

1. 先设硬性门槛，再进行加权评分

我建议先把“必须满足”和“值得比较”分开。硬性门槛适合做淘汰项，例如必须能按组织要求部署、必须满足某类权限管理、必须支持数据导出、必须通过安全审查。任何一项不满足，先停止比较，不要用其他优势抵消一票否决条件。

通过硬性门槛后，再用加权评分比较适配度。以下权重是启动评估的建议基准，不是行业统一标准。组织可以按项目类型调整：强依赖工程计划的团队提高计划与依赖权重；中大型组织提高治理与运维权重；小团队则提高易用性和配置成本权重。

2. 评分必须绑定证据，不用印象打分

每项评分都应附上证据：试点中的操作记录、供应商书面说明、合同条款、技术文档或用户反馈。比如“易用性得4分”不是证据；“五名首次使用者中，四人无需协助完成任务创建，三人能独立更新状态”才是可以复核的观察。

小样本结果不能伪装成普遍统计。团队内部的五人试点，只能说明这五位参与者在特定版本、特定任务下的体验。记录日期、版本、测试任务和参与角色，才能让后续评审理解结论边界，也方便版本变化后复测。

3. 把供应商承诺转成验收条件

“支持自定义流程”应转成具体检查：谁能配置、配置粒度到什么层级、修改是否影响历史项目、是否需要供应商服务、后续升级是否会覆盖配置。“支持数据导出”也应确认导出对象、格式、字段、附件、权限和频率，而不是只看是否存在一个导出按钮。

每条关键承诺都可以写成“条件，操作，期望结果，责任人”。例如，在测试组织内将成员分成项目负责人和外部协作者，分别打开同一项目，核验可见字段、可执行操作和审计记录。通过这类验收条件，采购讨论就能从形容词转向可检查的结果。

4. 评价易用性时观察真实行为

问卷里的“觉得好不好用”容易受演示效果和新鲜感影响。更有价值的观察是：成员是否按要求更新任务，状态是否在约定时间内同步，是否出现重复录入，负责人是否仍然维护另一张影子表格。工具真正进入工作流后，这些行为比主观印象更能说明采用成本。

可以用少量指标帮助试点复盘，例如任务信息完整率、周更新及时率、重复录入次数、未授权访问发现数和报表生成耗时。指标应只服务于决策，不要为了做量化而制造复杂统计。试点前先定好定义、取数方式和观察窗口，避免试点结束后临时挑选有利数据。

五、具体案例与数据观察：用试点发现真正的成本

1. 一个跨部门交付团队的情景推演

以下案例是为说明试点方法而构造的情景推演，不对应真实客户，也不是任何产品的实测结果。假设一家约120人的企业服务团队，同时运行8个交付项目，项目成员来自销售、实施、研发和客户支持。项目负责人每周从群消息、表格和会议记录整理进度，管理者在月末才汇总延期与资源冲突。

这类团队常把采购目标写成“需要甘特图和项目报表”，但真正需要验证的通常是三件事：更新是否能够回到统一项目记录，计划变化是否能保留原因，跨项目资源冲突能否提前暴露。若只是把原有表格搬进新界面，却没有减少信息重复流转，系统上线并不会自动改善管理。

试点可以选两个项目：一个按期推进、一个存在多方依赖。负责人将工作拆成里程碑和任务，成员按约定频率更新状态，管理者每周检查风险和阻塞。测试期间记录三类数据：更新信息花费的时间、从发现延期到定位原因的时间、每周维护的重复记录数量。只要团队能持续记录，这些数据就比“大家觉得顺不顺”更有决策价值。

2. PingCode 示例应如何进入候选评估

如果组织把 PingCode 纳入候选清单，应把它当作待验证的产品对象，而非先验结论。尤其对于中大型企业及100人以上组织，评估重点通常不止个人任务操作，还包括组织空间如何划分、权限如何管理、跨团队信息如何汇总、系统如何与现有流程协作，以及长期服务边界是否清晰。

试点之前，建议采购方先确认当前产品版本覆盖哪些实际需求，再把候选产品的功能、部署、价格和安全要求逐项填进统一表格。不要仅凭品牌定位推断某个模块一定可用，也不要把演示中出现的能力等同于采购版本承诺。具体功能、价格、部署选项和服务范围需以当前版本和书面材料核验。

这类谨慎不是降低推荐价值，而是让推荐可以被采购团队复核。某产品如果在试点中通过流程验证、组织治理、安全审查和成本评估，就可以进入商务谈判；若关键限制没有书面答复，就应保留备选方案，而不是在文章或会议中把未知项说成优势。

3. 试点数据怎么记录，避免只留下印象

试点数据可以建立一个简单的前后对照表，但要注意“前后”必须使用相同口径。比如过去每周项目汇总耗时按实际记录计时，试点期间仍由相同角色、按相同项目范围记录；否则不能把差异归因于软件本身。

有些结果不适合短期下结论。项目交付准时率受项目难度、客户变更和人员配置影响，不应仅凭两周试点就归因于工具。短期更适合观察过程指标：信息是否更及时、风险是否更早被发现、重复录入是否减少、关键状态能否由管理者自行获取。

4. 试点中的反常识发现：上线初期工作量可能先上升

我不建议把“上线即省时间”作为试点的默认预期。新系统刚启动时，团队可能要并行维护旧表格和新平台，补录历史任务，调整权限，学习字段含义。短期工作量上升并不一定意味着产品失败，但如果两三轮迭代后仍需要重复维护，说明流程设计或集成方案可能没有解决根因。

因此，试点目标最好分阶段：第一阶段验证能否正确表达流程，第二阶段验证成员是否稳定更新，第三阶段再观察汇总效率和治理成本。只有当团队停止维护关键影子表格、信息错误没有明显增加，才适合判断平台是否真正进入日常工作。

六、产品与方案比较：按场景选择，不做无依据总排名

1. 轻量协作工具：适合流程简单、重视上手速度的团队

如果团队规模小、项目数量不多、主要工作是分配任务和追踪期限，优先看轻量协作工具。比较时检查任务是否能快速创建、视图是否便于项目负责人浏览、提醒是否可控、成员能否在移动端完成必要更新，以及基本的数据导出是否满足团队管理需要。

这类工具的优势通常是启动门槛低、配置较少；边界是复杂依赖、资源计划、治理和组合管理能力可能不够。若团队开始频繁维护第二套计划表、难以追溯变更，或管理者需要跨项目看资源负荷，就该重新评估是否要升级到更系统的项目管理平台。

2. 研发项目管理平台：适合需要串联需求和交付过程的团队

研发类候选应围绕团队真实工作流比较，而不是只看是否具有看板或迭代视图。重点验证需求如何拆成可执行工作、缺陷是否能关联版本、测试与交付状态如何记录、跨角色协作是否顺畅，以及现有研发系统的集成是否可靠。

此类平台的风险在于配置过多或流程过硬，导致团队为了符合系统字段而改变并不必要的工作习惯。试点中要确认流程可以适度配置，同时又不至于每个团队各自定义一套规则，最终让管理层无法统一汇总。

3. 项目组合管理方案：适合多项目、资源竞争和组织治理需求明显的团队

当组织同时运行多个项目，管理者需要的不只是单项目计划，还包括项目优先级、资源冲突、里程碑偏差、风险升级和组合汇总。候选产品必须让项目层与组织层的信息保持关联，避免成员在一个系统填任务，管理者再在另一张表里手工拼报告。

这类方案的代价通常是更长的需求梳理、配置和治理周期。若组织没有明确项目分类、责任角色和汇报节奏，先上复杂平台可能只会把混乱数字化。建议先统一最小共识：哪些项目必须纳管、项目负责人如何定义状态、哪些数据必须按周期更新。

4. 私有化或本地部署方案：适合数据与运维边界要求明确的组织

需要私有化或本地部署时，不要只比较“能不能部署”。还要核对升级由谁执行、漏洞修复周期、备份恢复责任、监控告警、容量规划、故障响应和管理员培训。产品部署在组织自己的环境，并不自动意味着安全责任已经解决。

此类采购应将技术评审、业务验收和运维交接并列进行。若内部没有稳定的系统维护人员，部署自由度带来的控制权可能同时变成维护负担。云端服务也不应被预设为不合规，需结合数据类型、合同约束和组织安全政策逐条判断。

七、采购前的行动建议：用最小试点验证最大风险

1. 第一步：写一页需求边界

在联系供应商之前，先用一页纸写清团队规模、项目类型、当前工具、主要痛点、必须能力、部署约束和预算周期。不要把“功能越全越好”写成需求，也不要把尚未确认的未来设想列为硬性条件。

需求边界至少回答四个问题：谁会使用，谁负责维护，哪些数据必须留在系统内，出现什么情况就视为试点失败。边界写清楚，演示就更容易围绕真实任务展开，也能减少不同供应商分别展示不相干功能造成的比较偏差。

2. 第二步：准备统一的测试项目

给所有候选产品使用同一组测试任务。任务不必多，但要覆盖日常工作中的关键节点：创建项目、拆解任务、配置负责人和日期、处理依赖、更新状态、记录变更、生成管理视图、导出必要数据。

如果组织有权限或部署要求，就在同一轮试点中安排管理员验证。不要等业务团队通过后才发现账号体系、外部协作或数据导出不符合要求。涉及高风险数据时，可先使用脱敏样本，避免为了测试把真实敏感信息上传到未经批准的环境。

3. 第三步：让不同角色各自完成操作

项目成员要完成日常更新，负责人要处理延期和依赖，管理者要查询跨项目状态，管理员要配置权限与基本规则。每个角色至少独立操作一遍，并记录所需协助、容易误操作的步骤和绕行做法。

观察时不要只统计“能不能做”。还要记录“做一次要几步”“是否需要重复录入”“权限错误能否被发现”“数据能否被正确理解”。这些细节可以揭示产品表面可用、实际协作成本偏高的情况。

4. 第四步：统一询价并测算三年成本

发给供应商相同的询价条件：用户规模、部署方式、模块范围、试点服务、培训、数据迁移、接口、服务响应、升级维护和合同年限。要求对方把一次性费用、年度费用、可选费用和未包含内容分开列示。

三年成本测算不必追求看似精确到个位数，但要避免只报软件许可费。若不同方案的运维责任差异明显，还应把组织内部预计投入的人力成本列出来。无法估算的项目可以单独标注，不要把未知费用当成零。

5. 第五步：试点结束后开一次“反方评审”

评审会上除了问“这款产品有哪些优点”，还要安排一位参与者专门提出不采用的理由：哪条流程最不自然、哪项承诺仍未书面确认、哪种权限场景无法通过、哪些人仍然维护旧表格、后续维护由谁接手。

这种反方评审不是为了否定候选，而是为了避免团队被演示和沉没成本推着走。若关键风险可以通过合同、配置或培训解决，就把解决动作写进采购条件；若风险无法消除，就应保留其他候选或缩小试点范围。

八、不同情况下的取舍：不必追求一次买到“最强”

1. 预算紧、团队小：优先减少维护负担

预算有限时，优先把钱花在核心工作流上，不要为了未来可能出现的复杂需求提前购买高阶能力。先选能覆盖当前项目、成员愿意使用、数据可以导出的方案，并设定复评时间。若半年后项目数量、人员协作或治理要求明显变化，再评估升级。

但低预算不等于不做验证。至少要确认免费或基础版本的用户限制、数据保留、导出条件、权限边界和后续升级成本。若关键数据无法导出，短期节省的费用可能转化为未来迁移成本。

2. 流程差异大：接受统一标准与局部配置之间的平衡

不同部门对项目阶段和字段的理解不一致时，完全统一可能阻力很大，完全放任又会造成无法汇总。更可行的做法是设定组织级最小标准，例如项目负责人、里程碑、状态、风险和更新时间必须一致，其他字段由团队按业务需要补充。

候选平台应支持这种“核心统一、局部灵活”的治理方式。试点要观察各团队配置是否可控、管理视图是否仍然可比。如果每个团队都建出完全不同的流程，组织级报表可能失去意义；如果配置限制过强，团队又可能回到影子表格。

3. 安全要求高：把部署选择与运维能力一起评估

要求本地部署或专有环境的团队，不能只看数据控制权，还要盘点内部是否有人负责安装、备份、升级、监控和故障恢复。若没有对应能力，部署方案虽然满足纸面偏好，却可能增加系统不可用或升级滞后的风险。

选择云端服务的组织，则应重点审查数据处理边界、账号与权限控制、服务协议、故障响应和数据迁出机制。部署方式没有脱离上下文的绝对优劣，最终取舍应由数据分类、合规要求、团队运维能力和业务连续性共同决定。

4. 组织正在快速变化：为迁移和调整留出空间

团队规模、项目类型和管理方式仍在变化时，过度定制会把当前假设固化成未来维护负担。优先采用可解释、可调整的流程配置，先建立必要数据结构，再根据真实使用情况增加规则。除非有明确业务或合规理由，不要在第一阶段就把所有例外情形都做成自动化。

同时，采购合同和数据安排要考虑退出路径。组织应知道如何导出项目、任务、评论、附件和关键关系，如何停止续费，如何处理历史数据。退出机制不是看衰产品，而是确保长期决策保持主动权。

5. 业务要求快速上线：缩小试点，不要省略验收

如果业务希望尽快上线，可以先选一个部门、一个真实项目和一组明确指标，而不是直接全员推广。范围小能缩短协调时间，也更容易找到流程问题。试点通过后再扩展到相似团队，保留反馈窗口和回滚方案。

上线速度与评估质量并不矛盾。真正需要避免的是把“开通账号”当作“完成上线”。至少要明确管理员、成员培训、数据导入、权限规则、支持联系人和试点复盘日期，否则系统可能在形式上上线，实际使用仍停留在原有沟通方式。

九、最终建议：让选型结论能够被验证、复盘和推翻

1. 结论不应是无条件排名

这次搜索结果没有提供足够的完整测评材料，所以我不会把它们改写成不存在的产品榜单。对读者更有用的，是知道不同团队该优先看什么、怎样识别营销话术与可验收能力的差别，以及如何把不确定信息留在待确认清单中。

如果团队项目少、流程简单，优先选择轻量、易用、数据可迁出的工具；如果研发链路复杂，重点验证需求、执行、测试和交付能否连起来；如果组织多项目并行，则把计划、资源、权限、报表和运维纳入同一评估；如果安全与部署约束严格，就让技术和安全团队参与候选筛选。

2. 下一步可以按这张清单执行

1. 写清楚场景：列出项目类型、参与角色、当前痛点和必须能力，控制在一页内。

2. 设定淘汰条件：明确部署、数据、权限、预算和集成等不能妥协的要求。

3. 建立统一试点任务：用同一个真实项目流程测试所有候选，避免各看各的演示。

4. 记录过程指标：观察更新及时性、重复录入、汇总耗时和成员独立操作情况。

5. 核对完整成本：统一比较软件、实施、迁移、培训、运维、扩容和退出成本。

6. 形成书面决策：写明选择理由、适用边界、待确认项、验收要求和复评时间。

我对项目管理软件选型的核心判断是：工具不会自动创造管理能力，但合适的工具能让任务、依赖、风险和责任更容易被看见。采购前最值得投入的时间，不是多看几份功能介绍，而是让真实使用者用同一条工作流试一遍，并把差异记下来。

如果只能带走一个行动建议，就从正在发生的项目开始，挑一条最常出错的流程，设定明确的试点期限和验收标准。能让团队少维护一份影子表、让延期原因更快被发现、让权限和责任说得清楚的方案，才可能成为适合自己的国产项目管理软件首选。