企业数字化转型走到供应链阶段，SRM几乎是绕不开的一环。原因很简单：供应商不只是“下单对象”，而是直接影响交付、成本与风险的关键变量。用好SRM，能让采购从“靠人盯”变成“靠系统跑”，从混乱协同变成数据闭环。

但现实里，很多企业在选SRM时卡在一个问题上：
到底选国际知名SRM平台，还是选国内厂商？

其实这两类产品没有绝对优劣，核心在于：你的业务范围是否全球化？你的采购流程复杂到什么程度？你更看重成本还是标准化能力？
下面我们来详细对比一下，帮你少走弯路。

一、国内SRM厂商

过去几年国内SRM市场发展很快，这背后很关键的一点是：国内企业的采购协同方式、票税合规、审批习惯、供应商沟通工具都很本土化，本土厂商自然更“懂流程”。

目前较有代表性的国内厂商包括：正远科技、金蝶、用友。

1、正远科技：全流程智慧协同，多行业适配能力强

https://www.zhengyuantech.cn/

如果用一句话概括正远科技的优势：把采购全流程做细做透，并且真正能落地到日常采购协同。

它的SRM不是“堆模块”，而是围绕供应商全生命周期搭建体系，从准入到退出都有对应机制，适合希望“把供应商管起来、把采购跑顺”的企业。

（1）供应商管理中心：准入+档案+绩效闭环

供应商资质、证照、能力信息统一管理

资质到期自动预警，减少合规踩坑

（2）价格管理中心：寻源方式丰富，控成本更有抓手

比价、询比价、招标、竞价等场景覆盖

可构建物料价格库与历史趋势对比，让成本管理更“有数据”

（3）采购执行协同中心：订单—收货—对账—发票在线协同

这是企业用起来最容易直接感知价值的部分：

订单、到货、对账、开票在线协同

减少Excel来回、邮件沟通，协同效率提升明显

（4）数字化决策中心：把采购数据变成可用报表

采购周期、价格趋势、供应商表现可视化

采购管理从“经验决策”转向“数据决策”

（5）系统集成能力：能跟企业现有信息化系统打通

对接ERP、MES、WMS等常见系统

同时支持移动端协同，贴合国内采购人员工作方式

整体来说，正远科技更适合：采购流程多、寻源方式多、供应商数量多、对协同与合规要求高的企业。

2、金蝶：轻量化云产品，适合中小微快速上线

金蝶的风格更明确：轻量、云化、成本友好。
如果企业采购流程并不复杂，重点是“赶紧把协同跑起来、别再靠Excel”，金蝶SRM通常会更合适。

（1）订阅制云模式，投入更低

免服务器、免复杂部署

市场资料中常见口径：基础订阅价格“年费1.2万元起”（属于订阅型产品常见区间）

（2）功能聚焦刚需场景

供应商准入、订单协同、对账结算等需求覆盖充分

操作门槛低，供应商协同更顺

（3）更适合“第一套SRM”

优势是“快、轻、省”；不足是高级治理模块相对少。适合中小微企业或成长型企业先解决协同效率问题。

3、用友：ERP协同优势明显，适配中大型企业一体化管理

用友SRM的核心标签是：与ERP生态一体化能力强。
如果企业原本就在用用友ERP，或者希望实现“财务+采购+供应链”协同治理，用友会更顺畅。

（1）适配集团化、多组织、多层级审批

（2）覆盖复杂生产物料与多工厂协同

（3）适合有IT团队、预算较充足的中大型企业

用友体系往往“更重”，对应的实施周期与成本也更高，更适合规模化采购治理需求明确的企业。

二、国际知名SRM平台

国际平台在跨国企业里使用广泛，本质优势在于：
全球供应商网络、多语言多币种、标准化治理体系成熟。

但如果企业主要业务在国内，落地时常见挑战是：

①本土流程与票税习惯差异

②国内协同工具与支付方式适配

③交付成、实施周期、长期TCO偏高

④代表平台包括SAP、Oracle、Coupa等。

1、SAP：全球化寻源与协同标杆，跨国集团首选之一

SAP的优势非常典型：全球化标准体系成熟，适合全球采购治理。

（1）全球供应商协同网络覆盖广

SAP的Business Network/Ariba体系可支持大规模供应商在线协同，覆盖范围广、适配全球协同。

（2）供应商风险与绩效体系成熟

适合供应链层级复杂、采购体量大的集团化企业。

（3）挑战：本地化与成本门槛

对国内企业来说，SAP常见问题是：

①本地化需要二次适配

②实施依赖认证团队

③成本与周期对中小企业不友好

2、Oracle：功能全面，适合大型集团复杂场景

Oracle SRM体系偏向“全覆盖、强扩展”，同时和Oracle自身生态结合紧密。

（1）适合高定制、强治理的大型集团

（2）适合已使用Oracle技术栈的企业

（3）挑战：IT门槛高、实施成本高、周期长

3、Coupa：支出管理与分析强，重视精细化费用治理

Coupa的独特价值在于：支出管理与分析能力强，尤其适合重视预算、费用、付款治理的行业。

（1）支出分析与费用治理能力突出

（2）支持早付折扣/动态折扣等工作资本优化功能（Coupa官方也有相关功能资料）

（3）挑战：本土流程适配与综合成本

国内企业用Coupa往往需要更多本地化对接与流程适配，且对中小企业的性价比不高。

三、国际与国内SRM核心特点对比

1、适配场景：本土优先 vs 全球优先

国内厂商：适配国内流程、政策合规与协同工具

国际平台：适配全球化寻源、多语言多币种结算

2、成本与门槛：可控 vs 高投入

国内厂商：价格梯度灵活，上线快，维护成本低

国际平台：初始投入+实施成本+长期运维成本普遍更高

3、功能侧重：实用落地 vs 全面复杂

国内厂商：更偏“解决当下采购痛点”，迭代快

国际平台：功能体系成熟但复杂，中小企业易“大材小用”

4、服务响应：本地快 vs 全球标准化

国内厂商：本地交付资源多，响应速度快

国际平台：标准化强，但本地支持响应、沟通成本相对高

四、企业怎么选？

为了不选错，建议抓住三个关键词：规模、范围、痛点。

1、中小微企业（预算有限、流程不复杂）

优先选国内：

（1）想把采购全流程协同跑顺：正远科技

（2）更关注快速上线、轻量协同：金蝶云化方案

2、国内中大型企业（协同复杂、追求治理能力）

（1）希望与ERP一体化：用友优势更明显

（2）寻源方式多、供应商治理需求高：正远科技更贴合

3、跨国集团（多币种、多国家、多供应商）

（1）全球化寻源与标准化治理：SAP/Oracle等更占优势

（2）但必须评估本地化适配成本与实施资源，避免“上线难、用不深”

结语：SRM选型的本质是“适配”，不是“品牌”

SRM系统真正的价值只有一句话：
采购流程跑顺、供应商管住、协同变快、成本可控、风险可见。

国际平台强在全球化治理，国内厂商赢在本土落地。选型最怕的是：系统看起来很强，但落地后员工不用、供应商不配合、最终回到Excel。

因此建议你在选型时用一个标准去判断：
能否解决你的采购痛点，并被业务部门真正用起来。

墨天轮社区举办的 【文档悬赏令】系列活动，每次聚焦一个主题，征集真实、可操作的第一手文档，希望能扩充社区文档资源、为更多人提供有用的参考资料，让技术学习少走弯路！

第2号悬赏令活动主题：数据库巡检方案实践

数据库巡检是保障业务稳定运行的核心运维环节，更是DBA日常工作的重中之重。当前数据库类型、场景十分丰富，多数从业者需耗费大量时间整理巡检清单、调试巡检流程。墨天轮社区第二期【文档悬赏令】活动特围绕这一主题发起有奖征集活动，诚邀您上传实用、可落地的数据库巡检文档，和社区众位DBA们互帮互助，让巡检工作更高效、更标准！

一、活动时间

2026 年 1 月 26 日 - 3 月 28 日

二、文档要求

1、主题范围

本次征集聚焦 “数据库巡检” 核心主题，覆盖国内外主流数据库，基础巡检、专项巡检、自动化巡检等多类实用方案等均可，具体范围如下：

巡检主题细分（包含但不限于）：

• 基础巡检：日常运维巡检表/巡检清单/巡检手册
• 专项巡检：性能监控与优化巡检/灾备状态巡检/单机or集群巡检
• 方式：手动巡检标准化文档/自动化巡检/脚本命令/巡检工具

数据库不限：

• 商业数据库：Oracle、SQL Server等
• 国产数据库：达梦DM8、人大金仓KingbaseES、OceanBase等国产库
• 开源数据库：MySQL、PostgreSQL、Redis等开源库

2、合格要求与格式

文档内容需明确巡检目的、适用场景、巡检流程等，包含巡检相关代码（部分敏感信息可隐去）。

• 页数要求：≥5 页
• 必加标签：上传时需在 “标签” 栏填写 “数据库巡检” + 数据库种类（如 Oracle、OceanBase） 两个标签
• 支持格式：优先推荐 .doc、.pdf、.ppt、.md、.txt 格式（可支持前 5 页预览，下载率更高）；也可上传 .zip （需附内容说明）；

以下文档将被判为不合格：
1）主题无关：非“数据库巡检”相关主题
2）内容搬运：直接上传电子书或产品官方文档、他人演讲PPT，或直接复制抄袭、全文搬运网站其他文章/文档内容（已发布的文章内容不可以同时上传成文档参与活动，但如果是您曾发在其他网站的内容则可以上传参与）
3）流水账或凑字数：文档页数需≥5页，但不可通过凑字数、使用大量无关图片占篇幅等
4）作者刷量：不可刷数据-我们鼓励作者自发宣传自己的文档，但不可使用人工刷量、注册小号刷量等方式提高下载量；不可将文档拆分多份上传，导致单份内容无实际意义、缺乏完整性
5）重复文档：重新上传以前发布的文档系统会自动识别判定为重复仅自己可见，也不可删除旧文档后重新上传

三、上传步骤

1. 登录上传：登录墨天轮账号后，点击链接直达上传页：https://www.modb.pro/docUpload，或在首页下拉框点击 “传文档”；

2. 填写信息：

   • 标题：建议明确标注 “数据库种类 + 巡检场景”（如《MySQL数据库巡检手册》《Oracle数据库常规巡检项目和命令》），帮助他人快速判断主题
   • 标签：上传时需在 “标签” 栏填写 “数据库巡检” + 数据库种类（如 Oracle、OceanBase） 两个标签
   • 墨值设置：支持免墨值 / 5 墨值 / 10 墨值 / 25 墨值 / 50 墨值 / 100 墨值，设置墨值后，他人下载时支付的墨值将实时计入您的账户（ps：一般来说墨值越低下载门槛越低，被下载可能更高）

3. 提交：确认信息无误后点击 “提交文档”即可。于 “控制台-内容管理-我的文档” 处可查看您所有文档明细，若您遇到“仅自己可见”“转换失败”等状态可询问墨天轮小助手（VX：modb666）询问具体原因。

四、奖励设置

本次活动奖励分为 “合格奖”“有效助人奖”“巡检先锋奖” 三类

1、合格奖

每位用户每日首次上传≥5 页的合格文档，可自动触发 “每日任务” 获 5 墨值。此外，本次活动奖励额外可叠加，根据用户合格文档数量发放不同等级的墨值奖励，具体如下：

2、有效助人奖

根据单个文档下载数发放不同等级的墨值奖励，每个用户最多可有5个文档获得本项奖励：

3、巡检先锋奖

将综合评估用户上传的合格文档的内容质量及总下载量，评选出 “既多产、又优质” 的核心贡献者，发予相应奖励：

说明：三类奖项单独评奖、每位用户可重复获得。其中新版本先锋奖数量将根据实际参与情况灵活调整，若参与情况佳则可能增设、反之亦然。

五、奖励公布与发放

1. 进度公示：为了让大家更加了解自己的参与进度，将在活动期间不定期在活动原文评论区公布最新合格情况。若发现违规行为也欢迎向工作人员反馈，一经核实将取消其参与资格。
2. 结果公布：活动结束后 3 个工作日内公布所有获奖名单；
3. 奖励发放：墨值将在结果公布后 1-2 个工作日内发放至账户；实物奖励将通过私信收集地址，10 个工作日内寄出。

常见问题（Q&A）

Q1：如何让我的安装文档下载率更高？：
A：建议在标题、简介中写明 “适用版本 + 核心亮点”，若上传的是.zip 等无法预览的格式，可在评论区附关键步骤截图或内容大纲，帮助他人判断价值。

Q2：墨值可以干什么？
A：墨值是墨天轮社区的“通用货币”，可以用来下载付费文档、赞赏他人文章或进行提问赞赏、直播打赏、兑换商品、参与墨值拍卖等。具体可查看使用说明：https://www.modb.pro/db/446902。

Q3：我的文档会被展示在哪里？
A：文档上传成功后可在您的控制台、个人主页找到相应链接。管理员也会择优推荐到网站首页及文档页面，为您的文档增加更多曝光。若您觉得您的文档优秀，欢迎您转发分享或自荐给工作人员，我们将为您争取首页推荐、转发等更多曝光。

无论是你是初学者还是资深开发者，欢迎你加入本次文档悬赏活动，分享你的优质文档，与更多朋友一起学习进步！未来我们也将针对更多技术主题推出悬赏活动，如果你有推荐的主题也不妨告诉我们！乐知乐享、共同成长！

• 点击跳转上传文档：https://www.modb.pro/docUpload

往期活动导航
【文档悬赏令】第1号：数据库新版本的安装实操

欲了解更多可浏览墨天轮社区，围绕数据人的学习成长提供一站式的全面服务，打造集新闻资讯、在线问答、活动直播、在线课程、文档阅览、资源下载、知识分享及在线运维为一体的统一平台，持续促进数据领域的知识传播和技术创新。

关注官方公众号： 墨天轮、 墨天轮平台、墨天轮成长营、数据库国产化 、数据库资讯

十几年前，记得我刚做企业数字化咨询时，我总被客户问到同一个问题：“能不能在三个月内帮我们把报销、工单、库存管理全打通？”但每次我都只能苦笑。

那时候还没有很好的工具，而如果用传统编码开发就像盖砖房，从打地基到砌墙抹灰，一步都不能省，三个月也只够搭个框架。当时我就想，要是有套积木式的开发工具就好了，业务人员说要什么，我们随手搭一搭，几天就能交出能用的系统。

后来几年，市面上也陆续冒出来一些“快速开发工具”，我带着客户也试过好几款。但用下来总觉得差口气：

要么只能做些简单表单，稍微复杂点的流程就卡壳；

要么和现有ERP、CRM系统完全割裂，数据得手动导来导去；

最头疼的是，改个字段还要找技术人员，调整个审批节点要等排期，本质上还是没跳出“依赖专业开发”的怪圈。

直到这两年，尤其是2026年低代码平台集体升级后，我才真切感受到：那个“用积木搭系统”的时代，真的来了。它们不再过去是边缘型工具（只能做一些简单功能的系统），而是成为了能扛事的核心基建，真正把想法变应用的周期，从月级压缩到了周级甚至天级。

一、低代码平台定义：

（一）权威定义界定

Gartner在2025年底的报告里给过明确界定：低代码开发平台（LCAP）是通过可视化建模+少量脚本，快速搭建业务应用的工具，核心是把数据建模、流程编排、权限管控等模块做成可复用组件，让开发从“手写代码”变成“模块化装配”。

这话翻译成人话，就是把传统开发里重复的、标准化的工作都做成“现成零件”，技术人员只需补少量代码解决复杂逻辑，业务人员甚至能自己拖拽配置简单应用。

这里面，让我触动最大的是：我上周帮一家制造企业搭生产工单系统，用低代码平台把需求落地，全程只写了30行自定义脚本，这在以前是不敢想的。

（二）核心特征解析

真正靠谱的低代码平台，都逃不开三个核心特征，少一个都容易踩坑。

一是“可视化全链路”，从表单设计、流程编排到页面展示、报表生成，全程拖拽操作，业务人员盯着就能看懂，不用再靠技术人员翻译需求。

二是“高低代码融合”，这是2026年的主流趋势，既能让业务人员无代码上手，又能给技术人员留足扩展空间，比如用自定义脚本处理复杂计算，用API对接特殊系统。

三是“一键部署与版本管控”，比如支持Dev/Test/Prod多环境隔离，应用改坏了能一键回滚，避免上线后出问题没法补救，这对中大型企业来说真的特别重要。

（三）企业价值落地

低代码的价值从来不是省代码，而是“提效率、降门槛、保灵活”。

我服务过的一家装备制造客户，用低代码打通了订单需求、研发项目与生产交付全链路，以前要跨3个部门、花两周才能理顺的需求追溯，现在在系统里一点就能查全，出错率下降了70%。

对中小企业，它能快速补齐数字化短板，不用花大价钱请外包团队；

对大型企业，它能支撑高频的业务迭代，比如市场部门要做活动报名系统，当天提需求当天就能搭好上线；

对技术团队或软件外包公司，它把程序员从重复劳动里解放出来，聚焦核心业务逻辑，人效至少提升2倍。

二、企业低代码平台选型核心框架：

这十几年帮客户选型踩过无数雷，我总结出一个道理：低代码选型不是看单一功能多炫，而是看能不能适配企业的真实场景。

以下五个维度，少一个都可能导致项目失败。

（一）技术架构适配性

架构是底子，底子不稳后期必崩。我见过一家连锁企业，前期选了国内某轻量型零代码平台，门店扩张到50家后，系统直接卡顿崩溃。

因为平台不支持分布式部署，数据处理能力跟不上。

要想避免此类问题发生，我建议大家选型时重点看这三点：

一是是否支持微服务与云原生，适配企业后期扩张；

二是多环境隔离与版本管理，避免开发、测试、生产环境互相干扰；

三是移动端适配与离线能力，尤其是门店、巡检等场景，离线表单与数据同步功能必不可少。

（二）功能完整性与场景适配

不同平台有不同的特性，适配场景天差地别。比如有的平台擅长审批流程，有的擅长数据看板，有的则适配复杂业务建模。

我通常会让客户先拿一个核心场景试手，比如采购审批、工单管理，看平台能否覆盖全流程。

以采购场景为例，要能实现需求提报、供应商选择、合同审批、入库对账全链路配置，还要支持自定义校验规则，比如超过10万金额自动触发多级审批，这样才算是真正适配业务。

（三）AI融合深度

2026年的低代码平台，AI能力的评估也很重要。但也要分清“伪AI”和“真AI”。

有些平台只做了代码片段生成，顶多省点打字时间；而真正的AI融合，是贯穿开发全链路的。

我上个月试用一家企业级AI低代码平台，用自然语言说“搭建一个销售台账，自动统计每月业绩并生成报表”，AI直接生成了数据模型、表单页面和统计逻辑，我只需要微调字段名称就行。

这里面更实用的是智能调试功能，系统能自动排查流程卡点，比人工找bug快多了。对业务人员来说，这种“自然语言转应用”的能力，才是真正降低了使用门槛。

（四）生态集成与数据能力

企业数字化不是从零开始，低代码平台必须能和现有系统打通贯通，否则就是新的信息孤岛。

我帮客户选型时，一定会做集成测试：能不能对接SAP、Oracle等传统ERP，能不能和企业微信、钉钉、飞书打通推送，能不能从数据仓库拉取历史数据。

优秀的低代码平台通常有丰富的现成连接器，支持REST API、Webhooks等多种集成方式，还能实现可视化数据映射。比如把ERP里的库存数据同步到低代码工单系统，字段对应错误能自动提醒，不用技术人员逐行核对。

（五）安全合规与服务保障

对金融、政务、制造等行业，安全合规是红线。选型时要重点看：

是否支持私有化部署，满足数据本地化要求；

是否有行级、字段级权限管控，避免敏感数据泄露；

是否通过ISO27001、等保安全等资质认证，操作日志是否完整可审计。

此外，后续的服务保障也不能忽视掉。我有个客户之前就被某平台售后搞的哑口无言。平台出现了一个问题，售后三天才响应，导致客户业务停滞。

所以，这一块要擦亮眼睛，深入评估。

三、2026年主流低代码平台推荐

这大半年我实测了市面上十多款低代码平台，结合不同行业场景，筛选出三款综合能力突出、适配性强的平台，各有侧重，可按需对号入座。

（一）织信低代码平台

织信的核心优势是“中大型企业复杂场景适配”，团队核心成员来自华为、平安，对企业业务管控和系统集成的理解很到位。我们团队目前是织信低代码平台的代理商。我们也是仔细筛选评估了4个月，最终才选择的织信。

他们最吸引我们的点是：一，功能很强大，算是国内顶尖的，拓展性强，这个我跟他们团队开过一次线上会议，就已经感受到了。二，合作模式性价比很高，买断式+SaaS多租户模式，可以让我们也有自己的利润空间。

我记得去年在帮一家工程设计院选型时，也是用织信低代码打通了投标立项、客户需求、设计任务与成果交付全链路，最惊艳的是它的业务对象建模能力，能把需求、任务、成本、预算等模块深度关联，实现全流程追溯。

它支持私有化部署，满足集团型客户的数据主权需求，OpenAPI能力也很强，能轻松对接SAP、Oracle等传统系统。适配场景集中在军工、制造业、工程建筑、战略咨询、金融服务等行业，适合有复杂业务逻辑、强集成需求的中大型企业。不足是标准化模版偏少，中小企业如果没有IT人员，上手需要一定的学习成本。

（二）网易CodeWave

网易CodeWave的亮点是“AI原生与全栈智能化”，以网易自研大模型为底座，把AI能力贯穿开发、测试、运维全链路。我用它搭建运营活动管理系统时，只说“做一个带报名、核销、数据统计的活动页面”，AI就自动生成了页面布局、交互逻辑和统计报表，还能通过AI测试机器人自动排查bug，效率比传统开发提升一倍多。

它采用自研NASL语言，支持多人协作开发，在游戏、电商、金融等行业有丰富内部实践，某大型国有银行用它开发台账管理、结算管理系统，提效降本达60%。适合对AI能力要求高、追求快速迭代的互联网企业和中小企业，不足是生态连接器数量比泛微少，对接部分传统系统需要额外开发。

（三）泛微e-builder

泛微e-builder胜在“协同能力与生态成熟度”，作为老牌协同办公厂商，它天然适配企业内部协同场景，支持无代码、低代码、全代码三种构建模式，业务人员能拖拽搭建轻量应用，技术人员可通过全代码模式定制复杂系统。

它的AI融合能力很实用，上传Excel或用自然语言描述需求，就能自动生成应用，还能对接企业微信、微信，实现内部员工与外部客户、合作伙伴的实时协同。云商店有上千款成熟应用模板，覆盖87个细分行业，开箱即用，适合重协同、需要快速落地标准化场景的中大型企业，尤其是集团型组织。缺点是在极端复杂的业务建模场景，灵活性不如织信。

总结：低代码的核心是“让业务驱动技术”

十多年从业下来，我见证了低代码从小众工具到企业数字化核心基建的转变。2026年的低代码平台，早已不是“少写代码”那么简单，而是通过AI赋能、生态集成，实现了“业务人员能上手、技术人员能提效、企业能快速落地需求”的闭环。

选型时不用盲目追功能最全，而是要找准企业的核心需求：中大型企业复杂场景选织信，重协同、要标准化模板选泛微e-builder，追AI效率、快速迭代选网易CodeWave。记住，低代码的终极价值，是让技术不再成为业务的瓶颈，让每个企业都能拥有“按需搭建系统”的能力。

未来两年，随着AI与低代码的深度融合，“人人都是开发者”或许真的会成为现实。而对企业来说，提前布局适合自己的低代码平台，就是抓住数字化转型的快车道。

作者：Julia Vural，Percona 工程师。

原文：https://www.percona.com/blog/separating-fud-and-reality-has-m...，Jan 22, 2026

爱可生开源社区翻译，本文约 900 字，预计阅读需要 3 分钟。

过去几周，MySQL 社区再次出现关于 “Oracle 已停止开发 MySQL” 或 “MySQL 将被放弃” 的说法，引发了更多讨论和担忧。一些图表显示，2025 年 10 月之后 GitHub 的提交数量似乎停止增长，而一些博客文章和论坛讨论也对这些迹象进行了字面解读，这进一步加剧了人们的担忧。

作为一名公开分析过 MySQL 代码库活动，并且每天都在 Percona 公司使用 MySQL 的人，我想清楚地区分数据实际显示的内容和数据未显示的内容。

这篇文章并非对 Oracle 的盲目辩护。我们常常不同意 Oracle 的某些决定，并且会公开表达我们的观点。但公平至关重要——尤其是在恐惧、不确定性和怀疑（FUD）开始影响客户和更广泛的生态系统时。

关于“停止对 MySQL 维护”的说法

我们最近收到社区一个令人惊讶的问题：MySQL 真的被放弃了吗？他们还附上了 Otto Kekäläinen 的帖子中分享的图表。

这一结论通常是从 GitHub 公共仓库 的活动图表中得出的 ，该图表确实显示存在很长一段时间没有可见的提交。

图表本身没有错，但解读并不完整。

缺失的背景信息：MySQL 的实际开发过程

错误在于假设 MySQL 是在 GitHub 上开发的，但事实并非如此。

多年来，Oracle 一直遵循一套特定的工作流程，即在私有的封闭代码库中进行实时工程开发。GitHub 仅作为公共镜像和发布平台，而非活跃的开发工作空间。因此，代码会以大型的、整合的“代码包”的形式发布，与官方版本同步，而不是以每日增量提交的形式出现。

换句话说：

GitHub 是一个异步发布镜像，而不是开发记录系统。

这意味着：

• GitHub 上缺乏增量提交并不意味着缺乏开发。
• 预计版本发布之间会有较长的平静期。
• 突然的大规模提交爆发是正常的发布机制。

这种开发模式并不新鲜，它已经沿用多年。有人会说这不是 “真正的开源开发模式” 吗？也许会，但最终，在 2026 年 1 月 21 日（在最近发布的 9.6.0、8.4.8 和 8.0.45 版本之后）绘制的同一张图表 看起来不再像是被弃用了。

MySQL 的“弃用”案例完美地提醒我们，指标的价值取决于我们对所衡量系统的理解。

GitHub 图表上的停滞不前并不总是意味着项目正在走向衰亡；很多时候，它只是引擎在紧闭的大门后静默运转的体现。虽然我们可以讨论 Oracle 开发模式的透明度，但我们不应该将不同的工作流程误解为缺乏工作。事实并非总是如表面所见，以貌取人或以镜像来判断数据库都是错误的。

🧭 写在前面：为什么用“提及度”看 CRM 市场

这篇文章会以「在媒体与研究报告中被频繁提及」为线索，盘点几款在 2026 年依然保持高曝光的主流 CRM（注意：这不等同于任何官方榜单或权威排名）。

我会尽量引用权威研究机构、评测平台与行业媒体的公开信息，并从市场视角解释一件事：
为什么总是这些名字反复出现在关键报告、行业解读和选型清单里？

🔍 为什么“提及度”值得看？

在 CRM 领域，“提及度高”通常意味着三件事：

• 市场覆盖面广：跨行业、跨规模都能看到它的身影。
• 细分场景成熟：例如销售自动化（SFA）、服务管理、营销自动化等，都有清晰定位。
• 生态与口碑数据充足：集成伙伴多、实施与咨询经验多、用户评价可参考。

因此，当研究机构、评测平台或行业媒体在做趋势分析、产品对比、象限/波浪图，或者用户评价榜单时，这些品牌就会变成天然的“参照系”和“样本库”，被反复提到。

从不同角色的视角来看，大致是这样运作的：

• 研究机构视角
  以销售自动化（SFA）等子市场为评估单位，按功能完备度、愿景前瞻性、执行能力等维度进行对比（如 Gartner 对 SFA 市场的相关报告与解读文章）。
• 评测平台视角
  依托大量“已验证用户评论”，以评分、使用体验、市场热度等维度做动态排序（例如 G2 的 CRM 分类页，会列出热门产品并支持对比）。
• 行业媒体视角
  更关心“是否企业级就绪”“典型客户画像”“适配场景”，会在各种「最佳 CRM」「选型清单」文章中把这些产品列为常见备选。

🌐 2026 年提及度较高的几款主流 CRM

（按常见曝光顺序归纳，非严格排名）

下面这几款，是在研究报告、评测平台、行业媒体中都比较常被提到的产品。我会重点放在：它们为什么总出现在视野里。

1）Zoho CRM：性价比 + 套件化 + 全球化带来的高讨论度

Zoho CRM 的高提及度，主要来自两个层面：

• 研究机构 / 官方传播层面
  Zoho 官方公开资料中，会引用其在 Gartner SFA 相关评估中的定位（例如被归类为 “Visionary” 等，具体以官方引用和原始报告为准）。
  这一类传播，会把 Zoho 放进“有前瞻性的销售自动化供应商”语境下反复出现。
• 评测平台 / 用户口碑层面
  在 G2 等评测平台的 CRM 分类中，Zoho CRM 通常是热门产品之一。
  对潜在客户来说，它经常出现在“同类对比 + 用户评论”的选型路径里，尤其当用户搜索「性价比」「一体化套件」时，会很容易看到它。

综合来看，Zoho CRM 经常被提起，是因为它在预算敏感、但又想要完整业务套件的组织中，有稳定的心智位置。

2）Salesforce：企业级 CRM 的“默认参照系”

在很多讨论中，Salesforce 都被当作 CRM 的“基准线”来使用：

• 对于大型企业和复杂业务流程，Salesforce 一直保持强存在感；
• 围绕销售自动化平台（SFA）的行业与研究机构讨论中，它几乎是必被提及的对照对象；
• 生态与应用市场（AppExchange）、合作伙伴体系非常丰富，使它成为“生态型 CRM 平台”的典型样本。

因此，即使企业最后不选 Salesforce，也会拿它来做功能、价格与架构的对比参照。

3）Microsoft Dynamics 365：深度融入 Microsoft 生态的常见选项

Dynamics 365 的提及度，很大程度源自企业对“Microsoft 体系一体化”的偏好：

• 很多组织已经深度使用 Office 365、Teams、Azure、Power BI 等 Microsoft 产品，
  在此基础上选 CRM 时，Dynamics 365 的集成体验和统一账号/数据体系就变得很有吸引力。
• 在公开信息和市场传播中，也能看到微软围绕 Gartner SFA 相关认可进行宣传，这进一步巩固了它在“企业级 CRM 候选清单”里的曝光。

简单理解：只要企业是重度 Microsoft 用户，Dynamics 365 几乎一定会被提上讨论桌。

4）HubSpot：增长团队与中小企业的“常见第一反应”

在大量「最佳 CRM」「产品对比指南」「营销工具推荐」等内容中，HubSpot 经常出现，关键标签是：

• 上手快、体验好：对非 IT 背景的市场和销售团队很友好；
• 营销 + 销售协同强：从获客、内容触达、线索到销售跟进，有比较连贯的一体化体验；
• 定价与模块划分相对清晰，适合SMB 和增长团队从轻量开始逐步扩展。

因此，在“希望快速上线、重视获客转化闭环”的选型场景下，HubSpot 几乎是标配候选之一。

5）Oracle：大型企业与复杂业务版图中的常驻选手

在各类围绕 SFA/CRM 的机构解读与媒体综述里，Oracle 通常会与 Salesforce、Microsoft 一起被并列讨论，原因包括：

• 在大型企业和复杂行业场景（如金融、电信等），Oracle 仍然在应用版图中占据一席之地；
• 对一些已在 Oracle 体系中投入较多的客户来说，选型时会优先考虑在现有技术与数据体系上扩展 CRM。

因此，它虽然在大众媒体的“话题热度”可能不如某些新锐工具，但在企业级对比表格中依然有稳定席位。

6）SAP：从 ERP 体系延伸出来的 CRM 选择

在各种“企业级 CRM 供应商清单”里，SAP 也几乎是被固定写上的名字之一，典型场景是：

• 企业本身 ERP / 供应链 / 财务等核心流程已经高度 SAP 化；
• 在 CRM 选型时，更倾向于保持统一架构、统一治理与端到端数据链路。

因此，在谈到“是否适配集团级、制造业/复杂供应链企业”时，SAP CRM 通常会作为典型选项出现。

📊 一张表看懂：这些高提及度 CRM 各自擅长什么？

下面这张表，用更偏“选型语言”的方式，总结了这些产品在媒体/报告中的常见定位，以及更适配的典型场景。

这些定位之所以会被反复提起，本质上是因为它们分别占据了不同的典型购买路径：

• 生态型：以应用生态、ISV、合作伙伴为核心（典型如 Salesforce）。
• 平台型：强调与既有技术平台统一（如 Microsoft Dynamics 365）。
• 套件型：用一套工具覆盖多条业务链（如 Zoho CRM）。
• 增长型：优先服务营销 / 增长 / SMB 快速起盘（如 HubSpot）。
• ERP 延伸型：从既有 ERP / 核心系统向前台业务延伸（如 Oracle、SAP）。

🧩 对市场人员 / 选型团队的落地建议：如何“用好提及度”

“提及度高”不是终点，而是一个筛选入口。更实用的做法，是把它变成一个结构化的选型步骤：

1. 先按业务复杂度分层

把自己大致放在以下哪一层：

• 增长团队 / 早期阶段：
  目标是快速获客、跑通基础销售流程，对流程严谨度要求没那么高，敏捷和易用更重要。
• 多部门协同阶段：
  市场、销售、客服等多个团队需要在同一套系统里协作，对流程配置、权限、报表有一定要求。
• 集团化治理 / 企业级阶段：
  强调跨事业部、跨地区的统一流程、统一数据与内控合规，CRM 需要和大量已有系统集成。

你会发现，媒体与评测文章里的高频候选，刚好覆盖这三层典型场景。

2. 再看你更信哪种“证据类型”

可以有意识地分流信息来源，而不是把所有资料混在一起看：

• 如果你更看重口碑与易用性

  • 重点看 G2、Capterra、TrustRadius 等评测平台的用户评论和对比页面；
  • 筛选和自己行业、团队规模相似的用户体验，参考他们的“踩坑点”。

• 如果你更想站在研究机构的框架下决策

  • 关注细分市场（如 SFA、营销自动化、服务管理等）的象限 / 波浪图和公开解读；
  • 重点理解：他们在评估“执行能力”“产品愿景”“市场覆盖”时各自看重什么。

3. 最后靠 PoC 验证，而不是靠“提及度”下注

比较稳妥的路径是：

1. 把“高提及度产品”当作候选池入口，而不是结论；

2. 从中挑出 2–4 款，做一个 2–4 周的 PoC（概念验证）：

   • 用你的真实数据，把关键流程跑一遍：
     线索 → 商机 → 报价 → 合同 / 回款；
   • 同时验证：权限、报表、移动使用体验、对接现有系统等关键点；
3. 把“提及度 + 证据类型 + PoC 结果”综合起来再决策，而不是只看某一个维度。

这样做的好处是：你既借用了市场的“集体经验”，又保留了适配自身业务的判断空间，在预算和时间上都是更划算的决策方式。