做了三年国产替代选型这篇是我踩完坑后的全部经验三年前我第一次接到国产替代选型任务的时候心里的想法很简单不就是做个产品对比吗列个表打个分选个分数高的交差就完了。结果真做起来才发现这事儿的复杂度远超想象。三年里我前前后后参与了数据库、中间件、办公系统、工业软件等多个方向的选型项目大大小小加起来几十个踩过的坑一个比一个深交过的学费也一个比一个贵。回头去看选型这件小事其实藏着一整套方法论很多坑你不在里面滚一遍光靠看厂商宣传册和别人的经验分享根本意识不到。这篇文章我不打算讲空话套话就把这三年踩过的坑、最终沉淀下来的选型方法、以及和厂商博弈时那些台面上不会写的东西一次说清楚。如果你正准备做选型、正在被一堆指标对比表搞到头大或者已经踩了坑想找人印证一下这篇应该对你有用。1. 写在正式评估之前先想清楚这三件事否则后面全是坑大多数选型失败不是输在评估阶段而是输在评估开始之前。准备工作没做到位后面所有的测试、对比、评分都是空中楼阁。1.1 替代的到底是什么先梳理需求清单再去看产品清单我们最早做数据库替代的时候上来就直接约厂商宣讲连着听了一周的产品介绍感觉每个产品都差不多。直到后来准备做功能对比才发现自己连现状都没摸清现有系统里到底跑了多少个存储过程哪些定时任务每天在跑有多少第三方工具依赖数据库的特定特性全都没有头绪。没有现状基线做任何选型评估都是盲人摸象。正确做法是先做一轮彻底的现状摸排把资产盘点清楚然后输出一份结构化的需求清单。不是产品功能清单而是你们自己的业务需求清单。比如现有系统涉及哪些业务模块每个模块的核心功能是什么哪些功能是高频使用的哪些是一年才用一次的边缘功能有哪些外部系统接口依赖数据量和并发量大概什么级别。这份清单才是后面所有评估工作的基准线。我自己的习惯是把需求清单至少做到三级一级是业务域二级是功能模块三级是具体功能点和约束条件。每个三级功能点后面还要带上来源系统、使用频率、优先级、依赖关系等属性。这样拿给厂商看对方能明确告诉你哪些支持、哪些不支持、哪些需要定制沟通效率会高非常多。需求清单做扎实了后面做功能验证的时候测试用例也能直接复用一件事两处受益。1.2 业务边界在哪里替代范围、数据流向、接口依赖都要提前定义很多选型项目不是全量替换更常见的模式是部分替换、分批迁移、新老系统并行。边界不清是导致后续实施阶段扯皮的最大根源。有一次我们做ERP某个子系统的替代选型选型阶段只关注了新产品的单点功能没有细化它和周边系统的数据交换关系。结果到了实施阶段才发现这个子系统上游有三套系统给它供数下游还有两套系统消费它的数据中间涉及几十个接口的改造。本来以为三个月能上线最后拖了大半年。这个责任不在厂商完全是我们自己选型阶段没有把集成边界定义清楚。建议在选型启动之前就明确回答这么几个问题本次替代的范围具体是什么哪些功能纳入、哪些暂不纳入替代后的数据流向有哪几条每条链路的源端和目标端是谁有哪些接口需要保留、哪些需要改造、哪些可以废弃新老系统并行期有多长并行期间的职责边界如何划分。这些问题不搞清楚选型评估得再漂亮落地的时候一样会翻车。1.3 谁来用、怎么用用户习惯和培训成本是隐形的决策变量技术上很好的产品到了实际业务场景里未必好用。我见过太多选型项目技术团队测试报告写得很漂亮性能指标全部达标结果产品上线后一线用户强烈抵触最后被迫换回原来的系统。问题出在哪出在选型阶段根本没有把人的因素纳入评估。举个例子有一次做OA系统替代新的产品界面设计更加现代功能也更丰富但和原来的操作习惯差异非常大。老员工用了十年旧界面肌肉记忆已经形成新系统打开以后连发起审批这种高频操作都要重新找位置。上线一个月工单系统里全是用户提的功能不顺手反馈项目组每天都有人来质询。从那以后我要求所有的办公类、业务类系统选型必须安排关键用户参与试用评分。方法是设计几套典型的业务场景脚本让不同岗位的业务骨干在候选产品上完整走一遍流程然后从操作路径长度、功能可达性、学习曲线、界面友好度几个维度打分。选型不能只是技术部门拍板关键用户的意见应该占一定的决策权重。培训成本也要纳入总成本测算界面变化越大、用户群体越大这部分成本就越高。2. 三年里踩过的五个最典型的坑每一个都是血泪教训如果只让我讲一个部分我一定讲这部分。以下五个坑是我和团队实打实踩过的有的当时觉得天都要塌了有的事后复盘才发现根子在选型阶段就埋下了。2.1 第一个坑被兼容性100%的承诺打动上线后才发现是接口级兼容而非行为级兼容这是最典型、也是代价最大的坑。做数据库替代选型时厂商信誓旦旦说兼容我们原来的商业数据库迁移工具可以自动完成存储过程转换。我们当时听了很心动觉得这个迁移成本太低了立刻把它列为重点候选。POC测试时用一些简单的SQL语句验证确实都能跑通。但当我们把真实的业务存储过程放上去跑的时候问题开始暴露。复杂的存储过程大概只有六七成能通过迁移工具自动转换剩下的都需要人工改写。有些涉及递归查询、动态SQL、窗口函数嵌套的场景甚至要完全重写才能实现相同逻辑。更麻烦的是转换过去之后性能急剧下降原本毫秒级的查询变成了秒级有的复杂批处理任务慢了十几倍。教训是什么兼容性承诺必须拆成三个层次来看语法兼容、行为兼容、性能兼容。语法兼容只代表语句能解析执行行为兼容代表结果和语义一致性能兼容代表响应时间和资源消耗可接受。厂商说兼容的时候一定要追问是哪一层兼容。而且不能只听口头承诺要把兼容性验证拆成专项测试拿自己系统里最复杂的100个存储过程、最难搞的50条SQL去实际跑一遍看转换成功率、人工改写工作量、改写后的性能衰减比例。用数据说话不要被百分比话术迷惑。2.2 第二个坑被美化过的厂商性能报告带偏了方向每个厂商提供的性能测试报告看起来都很漂亮。吞吐量高、延迟低、并发能力强五彩斑斓的数据让人眼花缭乱。但如果你把这些数字直接当作选型依据大概率要吃大亏。有一次做消息中间件选型厂商报告里写的吞吐量很高我们自己的场景压测也验证了这个指标能达标。但到了生产环境跑了一段时间后发现响应时间波动非常大高峰期经常出现明显延迟。排查了很长时间才定位到问题我们的业务是典型的热点数据集中访问大量请求集中在少数几个队列上和厂商测试时均匀分布的数据模式完全不同。缓存命中率、锁竞争、队列热点分布这些在生产环境中的真实特征标准化测试根本覆盖不到。这个坑的根源不在于厂商造假而在于测试场景失真。厂商的测试环境、测试数据、测试模型和你的真实业务场景之间天然存在偏差。解决办法只有一个用自己的生产数据脱敏样本设计贴合自身业务特征的压测脚本在候选产品上做真实场景验证。测试数据要包含真实的读写比例、真实的并发模型、真实的数据分布特征。哪怕这样做出来的结果没有厂商报告那么漂亮但至少它是可信的。2.3 第三个坑稳定性验证做表面功夫长稳和故障场景没有充分暴露这个坑藏得更深。功能验证过了性能验证也过了结果在长稳测试阶段栽了跟头而且栽得很惨。某次消息中间件选型产品在功能测试、压力测试、并发测试中表现都很不错团队一度觉得已经可以定了。后来我坚持加了一轮7天长稳测试结果第三天开始发现问题内存占用持续攀升指标回收不掉最后直接OOM了。这个故障在厂商的演示环境和短期压测里根本不会暴露因为那些场景运行时间短、数据累积量小内存泄漏的曲线还没爬升到临界点。从那以后我们为这类基础软件选型定了一套稳定性测试矩阵起码包含四类场景长时间持续运行测试一般不少于72小时监控内存、句柄、连接数、线程数等关键指标故障注入测试模拟进程崩溃、网络中断、磁盘写满、节点宕机等场景容灾切换测试验证主备切换的正确性和RTO数据恢复测试验证备份文件和日志能否完整恢复。每一项都不达标就直接淘汰不抱任何侥幸心理。基础软件的稳定性问题一旦上线才暴露代价就不是几周时间能衡量得了的。2.4 第四个坑只盯着产品本身工具链配套没有提前验证很多选型评估只看产品核心功能很容易忽略一个事实产品上线之后是要长期运维的。如果配套的运维工具链不成熟开发和运维团队的日常工作量会成倍增加。这个坑我们是在一个基础组件选型过程中暴露的。那个产品本身的功能和性能都符合要求我们也基本敲定了结果深入评估运维工具的环节才发现问题很大。备份恢复只能通过命令行操作没有可视化界面监控指标没有对接我们现有的监控平台需要自己写采集脚本日志格式不标准现有的日志采集和分析链路接入困难。运维团队用了两个多月才勉强把这些坑填上比原计划晚了很多。建议在选型评估里增加一个独立的运维就绪度评估项让运维团队提前介入用一张检查清单挨个核对备份恢复能力是否完整、监控告警是否支持主流协议和平台、日志是否标准化、巡检工具有没有、扩容缩容是否方便、版本升级是否平滑支持回滚。这六项如果不过关哪怕产品功能再强后续的运维隐性成本也会让你怀疑人生。运维工具链不成熟的产品前面省下的选型时间后面运维一定会加倍还回去。2.5 第五个坑只选了产品没有选生态等于给自己埋了一颗长期雷这个坑不像前几个那么直接它的影响是慢性的但非常折磨人。我们在做一套办公系统选型时对比下来某产品的功能满足度最高、价格也最低很快就敲定了。但用了半年后问题开始浮现它的配套插件和周边工具非常少很多通用需求都要自己开发社区不活跃遇到问题去搜索引擎搜几乎找不到第三方的解决方案只能提工单等回复人才市场上熟悉这个产品的人也很少招人都困难。结果就是每次想扩展些新功能都会因为生态薄弱而变得特别费劲。后来我在选型评估框架里加入了生态评估这个维度并且想办法量化它社区活跃度包括论坛帖子数量、问题回复速度、版本更新频率文档完整度包括官方文档覆盖了多少功能、有没有中文文档、示例代码是否丰富人才供应情况包括招聘平台上相关技能的人才数量、培训机构有没有开课上下游产品集成度包括周边常用系统的适配情况、第三方工具的接入案例。生态看起来是很虚的东西但把它拆成这几个可量化的维度后就能在选型打分里实打实地起作用。3. 逐步打磨出来的选型评估框架五个维度缺一不可踩坑踩多了之后我慢慢形成了一套比较固定的评估框架。整个框架分为五个维度每个维度都有一套可操作的评估方法。不敢说这套框架完美但至少能让选型这件事从凭感觉变成用数据说话。3.1 功能性验证从能不能跑到跑得对不对功能性验证是所有选型评估的基础动作也是最容易被做浅的一步。很多团队的功能验证就是拿产品自带的demo点一遍看界面、看功能入口觉得看起来都有就算通过了。这样验证出来的结论完全没有参考价值。我现在的做法是把第一步做好的需求清单直接转成功能测试用例每条用例对应一个真实业务场景有输入、有预期输出、有操作步骤。执行的时候在候选产品上老老实实把每条用例跑一遍记录实际结果、偏差情况和操作路径。验证的目标不是能不能操作而是跑的结果对不对。比如报销流程审批不是看能不能提交报销单而是要看多级审批链路是否完整、金额超限时是否会被自动拦截、驳回后流程状态是否正確流转。边界条件和异常处理也一定要测。表单的极端输入、断网重连、并发提交、权限控制到按钮级别这些场景才是真正暴露产品成熟度的地方。功能性验证做完之后每条用例要有明确的结论通过、不通过、有条件通过。有条件通过的要写上需要什么条件、改造量大概多大、工期大概多久。这样到了综合评比阶段才能做真正的数据对比而不是拿着几页PPT拍脑袋。3.2 性能容量评估测试场景设计决定了结果的真实性性能容量评估的核心不是用什么压测工具而是测试场景设计得够不够真实。场景失真测出来的数据再漂亮都是自欺欺人。我在设计性能测试场景的时候一般会分成四类来测基准性能测试用标准化的场景验证产品的基础能力比如单条SQL的响应时间、单个请求的处理耗时业务负载测试基于生产环境的脱敏数据模拟真实的读写比例、并发模型和操作路径测出系统在典型业务负载下的表现峰值压力测试把并发数逐步往上抬找到系统的性能拐点看它在超预期负载下是优雅降级还是直接崩溃长稳和资源测试持续运行48到72小时观察内存泄漏、连接泄漏、线程堆积等慢性问题。性能指标维度上我最关注的是响应时间的P95和P99而不是平均值。平均值在数据分布不均匀的时候会严重失真P95和P99才能反映绝大多数用户的实际体验。另外还要看吞吐量的变化趋势、资源利用率与性能指标的关系、性能瓶颈出现在哪个环节。每一类测试都要设置明确的通过标准不达标直接淘汰不搞表现还行这种模糊表述。3.3 兼容性验证按完全兼容、有条件兼容、不兼容分级管理兼容性验证不能只看厂商提供的兼容性清单那玩意儿只能作为参考不能作为依据。真正有效的兼容性验证是要结合你们自己的实际环境来测。我一般会建一个兼容性矩阵像一张表行是各类兼容性项列是候选产品。矩阵至少要覆盖几个关键维度操作系统兼容性包括你们正在用的各版本Linux、Windows等数据库兼容性包括主流的几款数据库产品和版本中间件兼容性包括现有的应用服务器、消息队列等浏览器兼容性尤其是办公类系统要覆盖Chrome、Edge以及可能的国产浏览器内核硬件平台兼容性特别是涉及国产服务器芯片的场景外设兼容性比如打印、扫描等外部设备驱动是否能正常使用。测试结果按三个等级记录完全兼容、有条件兼容、不兼容。完全兼容就是开箱即用行为表现一致有条件兼容要写清楚前提条件比如需要安装哪个补丁、需要修改哪项配置、需要什么样的架构调整不兼容的要评估影响范围有没有替代方案改造代价有多大。这个矩阵做出来的意义在于它让兼容性从一个模糊的概念变成了一个可量化的表格。后期招标或者和厂商谈合同的时候这张表可以直接作为验收依据。3.4 可维护性与交付质量好产品不等于好维护到了这个维度选型评估开始变得现实了。一个产品哪怕功能再强、性能再高如果维护起来非常费劲长期来看依然是个大坑。可维护性评估我重点关注几个方面日志系统是否标准化日志格式是否包含时间戳、请求ID、业务上下文等关键信息日志轮转和采集是否方便告警能力是否完善有没有覆盖关键指标的告警规则告警渠道是否支持对接现有平台监控体系和主流监控工具的对接能力这个前面说过非常重要文档质量怎么样安装部署文档、运维手册、API文档、FAQ是否齐全且准确工具链成熟度怎么样备份、恢复、巡检、诊断、升级这些日常运维动作有没有配套的工具支撑。交付质量也要纳入评估包括交付物的完整性、代码质量、技术文档的详细程度、架构设计的合理性。我遇到过产品功能不错但代码里硬编码严重、参数配置文档缺失、后续配置改动要靠厂商工程师远程操作的情况。这种产品进了生产环境就是给自己请了个远程医生每次出问题都要等人上门。3.5 供应商综合能力评估看研发实力更要看服务落地选型选的不只是产品还有背后的厂商。厂商的综合能力直接决定了产品的演进方向和长期服务质量。评估供应商能力的时候我一般不怎么看宣传册而是想办法看几个硬指标版本发布节奏过去两年发了几个大版本、几个小版本bug修复的频率怎么样可以看出研发团队的活力和投入程度问题响应机制提一个技术工单实际响应要多长时间是标准回复还是真的定位到问题了服务机构覆盖情况在本地的服务体系是否健全有没有常驻的技术支持团队知识库和培训体系有没有成体系的文档、课程、认证能不能帮助团队快速成长客户成功案例有没有同行业、同规模、同场景的真实落地案例最好能实地走访到一个正在用的客户。供应商评估很容易被忽略的一点是支持团队的实际水平。有一次我们遇到一个疑难问题厂商的售后团队换了三拨人来处理最后也没能给出根本解决方案还是我们自己看了源码后分析出来的。所以后来我做选型一定会安排一次深入的技术交流带几个真正疑难的问题现场问厂商的技术专家看他们是否能给出有深度的回答。这比签合同前的礼貌拜访有温度得多也真实得多。4. 选型中的商务谈判与厂商博弈技术之外的隐形战场选型做到后面你会发现技术评估只是整个项目的一半商务环节的门道一点都不少。技术方案做得再好商务条款没谈好后续踩坑的风险依然很大。4.1 报价单里容易忽略的隐性成本采购价只是账本第一行很多人在看商务报价的时候只看产品本身的采购价格这是最大的误区。产品的总拥有成本远不止一张采购发票。我在做预算测算的时候会把成本拆成几个大块产品采购费包括License费用或订阅费用维保费一般占采购价的百分之十几到二十几每年都要交需要评估三年或五年维保的总成本占比升级费用大版本升级是不是要额外收费还是包含在维保里技术服务人天费现场支持、排查问题、定制开发按什么标准收费接口适配和集成费用和现有系统对接需要多少工作量培训费用是打包赠送还是单独计费深度培训的强度和时间怎么排。License的计费模型也特别值得关注。有的按CPU核数收费有的按实例数收费有的按并发用户数收费有的混合模式。计费模型直接决定了系统规模扩大后的成本弹性。曾经有个项目产品本身不贵但按核数授权我们在压测阶段为了性能把集群扩容了最终费用直接翻了一倍不止。所以商务谈判的时候一定要把计费模型、扩容策略对应的成本影响问清楚并把这个模型代入自己未来三到五年的容量规划里做测算。4.2 技术承诺如何落到合同条款口头承诺写不进去等于没承诺我见过太多选型项目和技术厂商开会的时候大家都很热情什么都承诺但到了签合同环节那些承诺就变得无影无踪了。技术承诺如果不落到合同条款里就只能是听个响。比较务实的做法是把技术评估阶段确定的关键指标逐一写成合同附件里的专用条款。比如性能指标方面P99响应时间不超过多少毫秒、吞吐量不低于多少TPS、长稳运行多少天无重大故障兼容性方面哪些功能点必须达到完全兼容等级、哪些场景必须通过专项验证服务能力方面生产环境问题的响应时限和解决时限、重大问题的升级机制和处理流程交付物方面需要交付哪些文档、代码、测试报告、操作手册。这些条款后面还需要附上对应的验收方法和测试方案约定什么标准算通过、什么情况算未达标。合同条款这件事上不要嫌麻烦更不要觉得对方是知名厂商应该不会有问题。越大的厂商流程越规范化口头承诺就越容易灵活。把所有指标和交付物写进合同附件是对合作双方都负责任的做法。条款写得越清楚后续执行的时候扯皮空间就越小。4.3 和厂商一起做POC的协作方式与边界主次关系一定要摆正POC概念验证阶段是选型过程中与厂商交互最密集的时期这个阶段的协作方式直接影响测试结果的可靠性。很多团队做POC受了厂商主导的方式影响测试方案是厂商出的测试用例是厂商准备的测试过程是厂商工程师操作测试结论是厂商汇总的。这样做出来的POC结果参考价值要大打折扣。厂商当然会把最好的一面展示出来这不是恶意而是人性。我的原则是POC测试方案必须由甲方来定测试用例必须基于自己的业务场景执行过程可以由双方配合但结果必须甲方自己复现。厂商可以提供技术支持、协助搭建环境、解答疑问但不能左右测试内容和测试结论。另外POC环境要和现有生产环境做到网络隔离数据用脱敏后的生产数据样本提前和合规确认数据使用的边界。POC周期也要留足至少两到四周这才足够完成功能验证、性能测试和长稳测试。POC阶段省时间项目后续大概率会花更多时间弥补。5. 从选型到落地的最后一公里实施阶段的坑与策略选型只是项目的前半段真正考验功力的是实施落地。如果说评估阶段犯的错还有机会修正实施阶段的坑就往往要付出上线延迟、业务受损的代价了。5.1 数据迁移与割接方案全量加增量、校验、比对一个都不能少数据迁移是几乎所有替代项目都绕不开的关键环节。很多项目在选型阶段不太关注数据迁移的细节到实施阶段才发现原来工作量这么大。数据迁移不是把数据倒过去就完事了里面的细节非常多。具体到操作层面我建议数据迁移至少覆盖这几个关键步骤迁移工具选型是用厂商提供的官方迁移工具还是用异构数据同步工具还是自己写脚本要综合考虑数据量、迁移窗口、技术难度迁移策略设计一般建议采用全量迁移加增量同步的方式先导全量数据再持续同步增量变更最后在割接窗口内做切换数据校验机制校验不能只比对行数要抽样比对字段值、校验主键唯一性、检查外键完整性、核对业务关键表的聚合结果割接窗口设计要选在业务低峰期预留充足的时间余量同时要做好整体的回退数据准备。我记得一个项目做数据迁移全量数据导了十几个小时增量同步也顺了校验发现行数对得上大家都很满意。结果业务系统一上线用户马上反馈部分单据数据有问题。后来排查发现是时间字段的时区处理不一致导致一批高频单据的实际时间都偏了几个小时业务流转直接错乱。所以校验这块行数对上只是入门级越细致越好尤其是日期时间、金额、状态、外键这类敏感字段一定要做针对性的深度比对。5.2 灰度方案与回滚预案上线不是孤注一掷是可控的渐进过程替代项目的上线最忌讳的是大爆炸式切换。一下把所有业务切过去出了问题连个缓冲时间都没有压力全集中在上线那一刻。稳妥的做法是设计灰度发布方案。先选择一个小范围、低风险的业务范围做试点验证新系统的稳定性和功能正确性运行一段时间没有问题后再逐步扩大切换范围。扩大的节奏可以是按业务模块切、按用户群体切、按流量比例切具体看业务类型。每扩一批都要观察一段时间确认指标正常后再推下一步。回滚预案更是重中之重。回滚不只是把配置改回去那么简单要提前考虑到几个棘手的问题数据在试点阶段产生了增量如何保证新老系统的数据一致性如果试点期间新系统写入了新数据老系统在进行最近一次全量切换时会不会受影响用户在试点期间的会话和临时数据怎么处理回滚的决策流程是什么谁有权决定回滚回滚操作的负责人是谁操作步骤是不是有演练过我建议把这几个问题整理成一个回滚决策检查清单上线前全员对齐一遍有条件的话做一次回滚演练。宁可多做无用功也不要在故障来临的时候才临时抱佛脚。5.3 团队培训与知识转移不能只培训操作要培养独立排障能力团队培训和知识转移经常是选型项目中最容易被压缩的部分。预算紧、时间紧培训往往被砍成半天甚至直接跳过。但恰恰是这部分投入不足会在上线后的运维期用更高的代价补回来。培训不能停留在会用的层面要达到能独立排查问题的程度。我建议培训分三个层次来安排基础操作培训面向所有使用者讲日常操作和常见问题处理运维运维培训面向运维团队包括环境、配置、监控、日志、备份恢复、常见故障排查和应急处理开发能力培训面向开发和架构团队讲产品架构原理、开发接口、性能调优、问题定位方法让团队具备一定程度的自主排障能力。培训结束后还要有考核考核形式可以用认证考试也可以结合实际操作来抽查确保不是听了个热闹。知识转移方面要让厂商把核心的技术文档、操作手册、应急预案都完整地交接过来不能只停留在有问题找原厂的层面。如果团队对产品完全依赖原厂支持每次出现问题都要等原厂来救火那这个选型项目的长期可维护性就打了折扣。5.4 上线后的持续验证与供应商绑定风险选型结束不等于项目闭环产品上线不意味着选型工作结束后面还有很长一段观察期需要持续验证选型的决策是否真正站得住脚。建议上线后设定三个月的重点观察期每月做一次复盘关键性能指标是否稳定在预期范围故障发生的频率和等级怎么样团队日常的运维工作量是不是在可接受的区间用户侧的反馈集中在哪些方面厂商的响应速度和服务质量是否达到了当初的承诺。这些记录要留档既是对选型结果的复盘也为后续同类项目积攒历史基线。上线三个月到半年后再做一次全面的回顾用它来校准当初选型评估里的判断权重。还有一个特别容易被忽视的问题就是供应商绑定风险。替代选型的核心目标可能是把原来的供应商替换掉但如果新选的产品在架构上、技术上让我们形成了新的深度绑定并且退出成本很高那就要保持一份清醒。架构设计上尽量采用标准化的接口和开放的协议避免深度依赖厂商的私有特性续费和更换周期要有明确的规划关键技术点要有自己的团队掌握不依赖原厂。替代选型的目标不是换完就算赢而是换了之后能持续稳定演进这两个境界差的不是一点半点。每次选型项目做完我都会把过程中的需求清单、测试用例、评估记录、问题清单、复盘结论整理归档。这些资料看上去只是项目的副产品实际过几年回看你会发现它们的价值远超过了选型本身。完整的选型历史数据下一次类似项目起步时的底气就是从这里来的。我个人的体会是选型这个活千万别怕前期慢。前期多用一个月把需求做细、把所有的坑都提前排掉后期能省下三个月甚至更久的时间。