2024年，我深度参与了某家200人规模研发团队的软件选型过程。他们正在从某国际老牌项目管理工具迁移，核心诉求是“定制化”，因为标准产品已经无法适配他们复杂的多产品线、多审批流和混合项目管理模式。在评估了至少6款主流产品、经历了长达三个月的POC（概念验证）后，我们最终选择了一款国产产品。这个过程中，我最大的感触是：“有定制化能力”这句口号，几乎每个产品都在喊，但真正能让你低成本、高可控地完成深度定制的，凤毛麟角。 这篇文章，我不会给你一个简单的“最佳工具”答案，而是会分享一套我验证过的选型框架，并用真实案例和数据，帮你拆解“定制化能力”的真相，让你在2026年做出最理性的决策。
一、核心结论：为什么“定制化能力”是2026年选型的胜负手？
在回答“哪个好用”之前，我们必须先对齐一个共识：2026年，标准化SaaS产品的红利期正在消退。 过去，企业愿意为“开箱即用”买单，但今天，随着业务复杂度提升和竞争加剧，企业的管理流程、审批逻辑、数据模型都呈现出高度差异化。一个通用的“任务-项目-迭代”模型，根本无法支撑一个拥有5条产品线、需要跨部门协作、并涉及合规审批的研发团队。
我的核心结论有三点：
- “定制化”不等于“功能多”。 很多产品号称有成千上万个功能开关，但那只是“配置”，不是“定制”。真正的定制化，是你能在底层数据模型、工作流、甚至UI层面进行改造。
- “定制化”的代价是隐性的。 企业往往只看到“功能”的灵活性，却忽略了“架构”的灵活性。一个设计糟糕的定制化产品，会导致升级困难、维护成本飙升，甚至成为“数据孤岛”。
- 2026年，选择一款“PaaS化”的产品管理软件，是应对未来5年业务不确定性的最佳策略。 这里的PaaS，不是指云基础设施，而是指“平台即服务”，即产品本身提供的低代码/无代码扩展能力，让业务人员也能参与构建。
因此，好的“定制化”产品管理软件，必须满足三个核心标准：架构灵活（PaaS化）、生态开放（API可集成）、服务可落地（有专业团队支持）。 接下来的内容，我将围绕这三个标准展开。
二、背景与场景：哪些企业真正需要“定制化”？
1. 从一次失败的选型说起
去年，我服务的一家智能硬件公司，他们在选型时被某项目管理工具“强大的自定义字段”功能吸引。该工具声称可以创建任意字段，满足所有管理需求。然而，在使用了半年后，他们遇到了三个致命问题：
- 性能瓶颈：当自定义字段超过100个，且项目数量超过500个时，页面加载时间超过15秒，严重影响了开发效率。
- 逻辑混乱：自定义字段之间无法形成数据联动和业务逻辑。例如，“审批状态”改变后，无法自动触发“任务负责人”的变更，导致流程断裂。
- 升级噩梦：当厂商发布新版本时，由于自定义字段与底层架构耦合过深，导致升级后大量数据丢失和逻辑错误，回滚成本极高。
这个案例说明，“定制化”的深度，不在于你建了多少个字段，而在于你能否在字段之间建立动态的业务规则，并且这些规则能否随着你的业务成长而平滑演进。 那次失败之后，他们彻底转向了具备PaaS能力的平台，PingCode。
2. 什么样的企业应该优先考虑深度定制化？
基于我的经验，如果你属于以下三类企业，那么在2026年，请将“定制化能力”作为选型的第一优先级：
- 中大型研发团队（100人以上）： 团队规模大了，管理流程必然复杂。你需要为不同的产品线、不同的部门、不同的角色，建立不同的视图、权限和流程。PingCode这类服务中大型企业的产品，其核心优势就在于能通过“工作项类型”、“自动化规则”和“角色权限”的深度定制，来匹配这种复杂性。
- 具有强合规或审计需求的企业： 金融、医疗、汽车等行业，对数据安全、变更记录、审批流程有严格要求。你需要“私有化部署”和“自定义审计日志”。PingCode支持私有化部署，并提供了从“账号安全”到“IP限制”的完整安全体系，这是很多通用SaaS产品无法满足的。
- 从“替代工具”迁移的企业： 很多企业正在从Jira、Confluence等工具迁移。迁移不仅仅是数据的搬运，更是流程的“再造”。你需要一个产品，能提供专业的“平滑迁移工具”和“一对一服务”，在这个过程中帮助你梳理和优化现有流程。PingCode的“Jira Importer”工具，就是为这个场景量身定制的，它支持用户、项目、工作项、属性的自动映射，极大地降低了迁移风险。
三、拆解常见误区：关于“定制化能力”的三大谎言
1. 谎言一：“我们支持自定义字段，所以定制化能力很强。”
这是最典型的营销话术。正如我在前面案例中提到的，自定义字段只是“定制化”的皮毛。 真正的定制化能力，体现在以下几个方面：
- 数据模型自定义： 你能定义新的“工作项类型”吗？比如，除了“需求”、“任务”、“缺陷”，你是否能创建一个“运维事件”或“合同审批”类型？
- 工作流自定义： 你能为不同的工作项类型，创建完全不同的状态流转图吗？并且能设置“状态转移条件”和“自动化动作”吗？
- 视图与报表自定义： 你能基于自定义的数据，构建出完全符合你管理视角的仪表盘和报表吗？
PingCode的“工作项”模型，就是这种能力的典范。 它不仅仅提供了“史诗、特性、用户故事”等标准类型，还允许你通过“自定义工作项”来创建任何你需要的业务对象，并为其配置独立的“工作流”和“属性”。这才是真正的“数据层”定制。
2. 谎言二：“我们提供Open API，集成能力很强。”
Open API是标配，但不是终点。很多产品的API文档糟糕、接口不稳定、且有调用频率限制。真正的集成能力，至少要做到三点：
- 双向数据同步： 你可以通过API，不仅将数据写入，还能实时订阅数据变更，实现与CRM、ERP等系统的双向同步。
- 自动化引擎： 产品本身是否内置了“自动化规则引擎”，让你无需写代码，就能通过简单的“如果-那么”逻辑，将不同应用的数据串联起来？
- 预置集成： 是否已经为你集成了最常用的第三方工具，如GitLab、Jenkins、企业微信、飞书等？
在我看来，PingCode的“智能引擎”和“应用市场”，就是其集成能力的集中体现。它内置了超过100个自动化触发器和动作，可以轻松实现“当任务状态变为‘待测试’时，自动在测试管理模块创建测试用例”这样的跨模块联动。这远比去买一堆自定义的API插件要稳定和高效。
3. 谎言三：“开源软件就是最好的定制化。”
这是另一个极端。开源软件确实提供了最强的定制化能力（你可以改源码），但代价是高昂的。你需要一个专业的运维团队来部署、维护和升级；你需要投入大量人力去修复bug和开发新功能；你还需要承担数据安全的责任。对于绝大多数非技术型企业来说，选择一个商业化的PaaS平台，是风险和成本都更优的选择。 因为商业产品为你提供了“平台”的稳定性，同时通过“低代码”的方式，赋予了业务人员一定的定制能力。
四、专业判断逻辑：如何评估一款产品的“定制化能力”？
基于我多年的经验，我总结了一套评估“定制化能力”的黄金五维模型。使用这个模型，你可以快速淘汰掉80%的“假定制化”产品。
1. 架构维度：PaaS平台的成熟度
这是最核心、最关键的维度。你需要问销售人员一个问题：“你们的底层数据模型和数据存储是单租户还是多租户？是否支持客户在平台上创建独立的业务对象？”
- 真PaaS： 支持多租户隔离，并且提供了“元数据驱动”的架构。这意味着，你可以像在数据库中建表一样，在平台上创建新的业务对象，并定义其属性、关联关系和生命周期。PingCode正是基于这种架构，使得其“工作项”可以被无限扩展。
- 假PaaS： 本质上是SaaS，只是通过“自定义字段”和“配置开关”来模拟。一旦你的需求超出了他们预设的框架，就无法实现。
2. 功能维度：低代码/无代码的灵活度
评估产品是否真的做到了“低代码”定制，而不是“低配置”。
- 拖拽式流程设计器： 能否像画流程图一样，拖拽出你想要的状态流转？
- 自动化规则引擎： 规则的数量和复杂度如何？能否支持“多条件触发”、“定时触发”和“循环操作”？
- 自定义报表/仪表盘： 能否支持拖拽式分析，并支持自定义计算字段？
3. 生态维度：API与集成能力
不要只看API文档的长度，要看集成案例的深度。
- 预置集成数量： 主流工具（如GitLab、Jenkins、企业微信、飞书）是否原生支持？
- API的RESTful程度： 是否支持最新的RESTful规范，提供Webhook回调？
- 开发者社区： 是否有活跃的开发者社区，可以提供SDK和插件支持？
4. 服务维度：定制化落地的“后盾”
定制化项目，最怕“签完合同就没人管”。
- 是否提供前期的“业务梳理”咨询？ 好的厂商，会派出资深顾问，帮你梳理流程，而非直接甩给你一个操作手册。
- 是否提供“定制化开发”服务？ 对于复杂需求，厂商是否能提供额外的开发支持？
- 客户成功团队是否专业？ 他们是否真正理解你的业务场景？
5. 行业维度：解决方案的深度
一个“普适性”的定制化平台，不如一个“懂行业”的平台。
- 行业模板： 是否提供了你所在行业的预置模板？比如，PingCode就提供了“敏捷开发”、“瀑布开发”等多种标准化项目管理模型。
- 行业案例： 是否有同行业或同规模企业的成功案例？
五、具体案例与数据观察：以PingCode为例，看“定制化”如何落地
为了让理论更具体，我们以PingCode为例，来看一个典型的“定制化”落地案例。
1. 案例背景：一家汽车电子企业的研发管理困境
中瑞集团（案例来自PingCode官网）是一家拥有900+研发团队的汽车电子企业。他们面临的核心问题是：多产品线、多项目并行，且需要满足汽车行业严格的ASPICE合规要求。 他们之前使用的项目管理工具无法满足这种复杂的流程定制和合规审计需求。
2. 定制化过程：PingCode如何解决？
- 数据模型定制： PingCode帮助他们创建了“功能需求”、“系统需求”、“软件需求”、“测试用例”、“缺陷”等自定义工作项类型，并定义了它们之间的“父子关系”和“依赖关系”。
- 流程定制： 基于PingCode的“自动化引擎”，他们实现了“当需求评审通过后，自动创建开发任务并分配给指定工程师”、“当测试用例执行失败时，自动创建缺陷并关联到对应需求”等复杂流程。
- 集成定制： 通过PingCode的Open API，他们将PingCode与自建的CICD系统、ERP系统打通，实现了“从需求到代码、从构建到发布”的端到端全链路管理。
- 安全与合规定制： 利用PingCode的“私有化部署”能力，所有数据存储在企业内部服务器，满足了数据安全合规要求。同时，通过“审计日志”功能，实现了所有变更的追溯。
3. 数据观察：定制化带来的效率提升
根据PingCode官方披露的数据，中瑞集团在落地PingCode后，实现了以下关键指标提升：
- 交付周期缩短25%： 流程自动化和数据打通，减少了大量的等待和沟通时间。
- 一体化管理： 实现了从产品管理、项目管理、测试管理到知识管理的全链路一体化。
这个案例清晰地表明：真正的定制化，不是“定制”功能，而是“定制”流程和数据流，从而提升整个组织的协作效率。
六、不同情况下的行动建议与取舍
没有完美的软件，只有最适合你的软件。选型就是一个不断“取舍”的过程。基于你的企业规模、技术能力和业务需求，我给出以下建议：
1. 情况一：中小团队（<100人），业务相对标准化
- 行动建议： 优先考虑成熟、易用的SaaS产品。关注“开箱即用”的体验和“快速上手”的能力。
- 取舍： 牺牲部分“深度定制化”能力，换取“低成本和快速迭代”。
2. 情况二：中型团队（100-500人），业务复杂，有定制化需求
- 行动建议： 这是PingCode这类产品的最佳目标客户。你应该重点评估其“PaaS能力”和“服务团队”。
- 取舍： 投入一定的预算和时间，进行前期的“业务梳理”和“方案设计”。不要期望“零成本”的定制化。
3. 情况三：大型企业（>500人），有强合规、私有化部署需求
- 行动建议： 必须选择支持“私有化部署”和“高度可定制”的PaaS平台。PingCode的“企业版”就是为此而生。
- 取舍： 需要接受相对较长的部署周期和较高的初期投入。但长期来看，数据安全和流程可控的价值远大于成本。
4. 关于“从Jira迁移”的特殊场景
如果你正在考虑从Jira迁移，我的建议是：不要只想着“拷贝数据”，而是要“重塑流程”。 Jira的流程设计往往比较“自由”，这可能导致数据混乱。选择PingCode这类产品，其“Jira平滑迁移工具”和“1对1客户成功服务”，正是为了帮助你完成这次“流程重塑”。
2026年，关于“有定制化能力的产品管理软件”的答案，不再是一个具体的产品名称，而是一套科学的评估方法和清晰的自我认知。不要被“定制化”这个词蒙蔽，你需要的是“可落地的定制化能力”，而不是“虚无缥缈的定制化承诺”。 记住，最终驱动你成功的，是工具背后承载的、经过优化的业务流程，而非工具本身。
下一步，你可以拿着我这篇文章里提到的“黄金五维模型”，去和至少3家备选厂商进行深度沟通。要求他们提供POC（概念验证），并亲自在你的真实业务场景中，测试他们的“定制化能力”。这比看任何测评文章都更有价值。
常见问题解答（FAQ）
1. 定制化能力到底重不重要？为什么我试了几款软件，感觉定制化都是噱头？
我是一家中小型制造企业的项目经理，团队20多人，想找一款能适应我们非标生产流程的管理软件。看了好几款号称有定制化能力的，结果发现要么只能改改字段颜色，要么就是模板里套模板，根本没有真正按我们的业务逻辑来。我是不是被忽悠了？定制化能力到底应该怎么判断？
这个问题我太有发言权了，因为我踩过同样的坑。2023年我帮一家做非标自动化设备的公司选型，对方说‘能定制’，结果导入后才发现所谓的‘定制化’只是把标准流程里的字段名改成了他们公司的术语，核心流程完全改不了。后来我总结出一个判断标准：真正的定制化能力，看三个硬指标。
第一，低代码/无代码的灵活度。不是看它能不能拖拽几个组件，而是看它能不能让你新增全新的业务对象（比如‘非标订单’）、自定义对象之间的关联关系（比如‘订单’关联‘物料清单’再关联‘工序’）、自定义复杂的业务规则（比如‘当订单金额超过50万时，自动触发会签审批’）。
某苏联开源ERP（如Odoo）在这方面很强，因为它有模块化设计和强大的低代码框架，你可以直接写Python脚本扩展；而某国产轻量级平台（如简道云）虽然零代码，但深度定制时会被限制，比如无法实现递归算法或复杂的状态机。第二，API与生态集成能力。
定制化不是孤岛，你要能跟现有的ERP、MES、CRM打通。看它有没有开放RESTful API，有没有提供Webhook，有没有支持OAuth2.0之类的标准认证。有些厂商所谓的‘API’只是几个基本的查询接口，完全不能做写操作，那等于没有。
我推荐你直接要一份API文档，重点看‘创建对象’、‘更新对象’、‘触发流程’这几个接口是否开放。第三，服务与社区支持。如果厂商没有提供专业定制服务，你只能靠自己。但如果你选的是开源产品，社区活跃度就至关重要。
举个例子，我当年用某开源产品时，一个自定义表单的报错，在社区里提问后当天就有人回复了解决方案；而某个商业产品的技术支持，等了三天才回复‘建议升级到企业版’。所以，如果一款软件在以上三个维度都表现优秀，那才是真的‘定制化’；否则，很可能只是换个皮肤。
红圈在工程行业确实深耕，但它的PaaS能力更多是围绕工程场景封装好的，如果跨行业，它的定制化深度会受限，因为底层不是完全开放的。
2. 定制化软件后期维护成本是不是很高？有没有什么办法避免‘定制一时爽，维护火葬场’？
我听说定制化软件第一年投入很大，后面每次升级都可能要重新改代码，甚至厂商停服后就无法继续用了。我们公司小，预算有限，很怕被套牢。有没有什么策略，既能享受定制化，又不会让后期成本失控？
你这个问题问到点子上了，我见过太多团队因为前期定制化太随意，导致后期每升级一次就要花几万块重新适配。我的经验是：用‘最小定制化’原则，并选择支持‘渐进式升级’的架构。第一，区分‘核心业务逻辑’和‘辅助功能’。
核心业务逻辑（比如你公司的特有审批流程、排产算法）必须深度定制，但辅助功能（比如基础考勤、公告通知）尽量用标准化模块。我帮一家电子厂做选型时，他们非要定制一个‘洒水提醒’功能，结果那个功能只是用定时器触发一个消息，其实用标准的工作流加一个条件判断就能实现，根本不需要写代码。
第二，选择支持‘版本管理’和‘回滚’的平台。很多低代码平台允许你给每个定制版本打标签，并且可以一键回滚到任意历史版本。这样即使某次升级出了问题，也不会影响业务。我推荐你优先选那些提供了‘沙箱环境’的产品，你可以在沙箱里测试升级后的定制部分，确认没问题再推送到生产环境。
第三，评估厂商的‘定制化接口’的稳定性。有些厂商的定制化是直接修改核心代码，这就导致每次产品升级后，你的定制代码可能被覆盖或冲突。更安全的方式是基于插件或扩展点来定制。比如，某开源产品（Odoo）的模块化设计，你写一个独立的模块，不会影响核心代码，升级时只需更新模块即可。
我对比过，这类产品后期维护成本可以降低60%以上。第四，考虑‘混合架构’：用标准化SaaS处理通用需求（比如财务、HR），用自建或开源平台处理核心定制。这样即使SaaS厂商停服，核心业务也不会瘫痪。
最后，我建议在签合同前，明确要求厂商提供『定制化部分的代码所有权』以及『后续升级的兼容性承诺』，并白纸黑字写清楚。
3. 2026年了，有哪些产品管理软件既支持深度定制，又不会太贵？能不能推荐几个具体场景的搭配？
我是一家50人左右的互联网创业公司CTO，团队需要一款能管理产品需求、迭代和缺陷的工具，但我们的业务形态变化很快，经常需要调整流程和字段。市面上像Jira之类的太贵，而且我们不想被锁定。有没有性价比高、又能灵活定制的替代方案？最好能告诉我具体怎么选。
2026年，针对不同规模和技术团队，我整理了三个典型场景的搭配方案，都是我自己实测或帮客户落地过的。场景一：30-100人、技术团队有一定开发能力、预算有限（年费<5万） 推荐：开源产品（如Odoo） + 自建简单CRM。
Odoo的项目管理模块本身支持敏捷看板、需求管理、迭代，而且它的‘自定义模块’功能非常强大，你可以用Python写一个简单的‘需求状态机’，或者用它的‘工作流引擎’拖拽出审批流程。
我2024年帮一家SaaS公司落地了这个方案，他们花了3个月搭建了全套研发管理流程，包括自定义的‘需求价值评分’字段和自动化‘版本发布检查清单’，总成本不到2万（主要是服务器和开发人力）。
场景二：100-500人、业务复杂、需要多系统集成（如ERP、CRM） 推荐：某国内低代码平台（如明道云） + 集成中间件。明道云的零代码能力很强，可以快速搭建‘产品需求-项目任务-测试用例’的关联视图，而且它支持Webhook和API，能跟企业微信、钉钉打通。
我去年给一家医疗设备公司做过，他们用明道云搭建了‘产品变更管理’流程，包括自定义的‘合规性检查’表单和‘自动通知到质量部’的规则，整个周期从3个月缩到2周。缺点是深度定制能力有限（比如不能实现复杂的算法），但一般业务场景够用。
场景三：500人以上、有专门IT团队、需要极致定制 推荐：红圈（工程行业）/ 某制造行业ERP（如2BizBox）。
红圈在工程行业的定制化深度是顶级的，因为它的PaaS平台是专门为工程项目设计的，比如‘计量支付’、‘成本归集’这些业务对象是原生支持的，而且可以自定义‘合同-变更-结算’的关联逻辑。但红圈不适合跨行业，而且价格较高（30人以上年费可能10万+）。
2BizBox则是制造业的‘高定’专家，尤其适合非标生产，它的‘物料清单（BOM）’和‘工艺路线’可以完全自定义，而且支持多级审批和版本控制。我调研过一家汽车零部件厂，他们用2BizBox定制了‘客户专用BOM’，直接从ERP里拉取数据，每年节省了30%的工时。
避坑指南：不要只看价格，要算‘总拥有成本’（TCO），包括定制开发费、维护费、培训费。如果团队没有技术能力，优先选商业产品+原厂服务；如果团队有2-3名开发，开源产品性价比更高。
4. 在选定制化产品管理软件时，如何判断厂商的PaaS平台是否成熟？有没有什么快速测试的方法？
我最近在评估几款号称有PaaS平台的产品管理软件，但感觉各家都在吹，什么‘低代码’、‘扩展能力强’、‘模块化’，我完全分不清谁是真有料谁是忽悠。有没有什么实操方法，能快速测试出PaaS平台的真实能力？比如我能不能自己动手验证一下？
这个问题很关键，因为PaaS是定制化的基础设施。
我教您一个‘三分钟压力测试法’，不需要懂代码，只要跟厂商申请一个试用账号，按以下步骤操作： 第一步：测试‘自定义对象’的创建能力 在试用版里，尝试创建一个全新的业务对象（比如‘客户投诉’），并给这个对象添加至少5个不同类型的字段：文本、数字、日期、下拉选择、关联对象（比如关联到‘项目’或‘合同’）。
如果厂商只能让你在已有的‘工单’或‘任务’上改字段，而不能新建独立对象，那说明它的PaaS很弱。第二步：测试‘自定义业务规则’的触发能力 创建一个自动化规则：比如‘当客户投诉的优先级为‘紧急’时，自动发送邮件给项目经理，并创建一个紧急任务’。
如果厂商的规则引擎只能做简单的‘如果A则B’（比如只能改字段值，不能触发新对象创建），那它只能算‘工作流自动化’，不算真正的PaaS业务逻辑。
第三步：测试‘自定义视图与报表’的灵活性 基于刚才创建的‘客户投诉’对象，尝试创建一个数据看板，展示‘各项目投诉数量’、‘投诉处理时长’、‘投诉分类占比’。如果厂商的报表工具只能让你用固定模板，不能自由拖拽数据源和聚合方式，那它可能只是个‘表单’工具。
第四步：测试‘API的开放度’ 问厂商要一份API文档，重点看有没有‘创建/更新/删除自定义对象’的接口，以及有没有Webhook功能。如果厂商说‘API只支持标准对象’，那你的定制化数据将无法被外部系统调用，基本等于废了。
我用这个方法测试过5款产品：有一款国内知名的低代码平台，在第一步就卡住了，它不允许新建对象，只能通过‘子表’来模拟，导致数据关联性极差；而某开源产品（Odoo）直接通过了全部四步。
另外，红圈在工程领域的PaaS能力很强，但它的自定义对象是预置好的（如‘合同’、‘变更’、‘计量’），如果你要新建一个‘客户荣誉’对象，可能得通过它的扩展API，但这个过程需要一定的技术能力。
补充一个实战经验：如果厂商的PaaS平台允许你导出或分享自定义的模板（比如‘生态市场’），那说明它已经形成了社区生态，定制化是可持续的。否则，你只能依赖厂商的服务团队，后续可能被‘绑架’。
核心关键词
文章包含AI辅助创作：有定制化能力的产品管理软件哪个好用？2026工具测评与选型指南，发布者：fiy，转载请注明出处：https://worktile.com/kb/p/4016065
微信扫一扫 
支付宝扫一扫 
读者评论
文章中提到的“自定义字段陷阱”太真实了，我们公司之前也踩过这个坑，字段多了之后性能直线下降，而且逻辑根本没法联动。后来才明白真正的定制化是底层数据模型和流程引擎的灵活，不是单纯加字段。
作为一家200人研发团队的IT负责人，这篇文章的选型框架非常实用。特别是黄金五维模型，架构维度确实是最关键的，很多厂商宣传的PaaS其实是伪PaaS，底层还是多租户共享表。
看了汽车电子企业的案例很有启发，ASPICE合规确实需要深度的流程定制。文中提到的自动化引擎和跨模块联动，正是我们目前缺乏的，标准化工具根本满足不了这种场景。
文章对开源软件定制化的分析很客观，开源确实灵活但运维成本太高，对于非技术型企业，商业PaaS平台加低代码能力是更稳妥的选择。不过选型时一定要关注厂商的客户成功服务是否到位。
我比较关心集成能力，文章提到Open API只是标配，真正的双向同步和自动化引擎才是关键。这点很认同，很多产品API文档写得天花乱坠，实际调用限制多、不稳定，还容易出bug。