写技术选型文章最怕什么？最怕一群人拿着网上不知哪台机器跑出来的压测数据争个你死我活，最后谁都说服不了谁。做后端这几年，我见过的每一次“框架之争”几乎都是这个套路：Go的和Java的吵，Node的和Python的吵，吵到最后拿不出同一条件下的对比数据，问题就变成了谁的嗓门大。
但真实的高并发项目容不得这种嗓门式决策。尤其是这几年，我接触过的系统里既有IM这种连接密集型场景，也有ERP库存这种事务密集型场景，还有API网关这种纯粹吞吞吐量的场景。同一个框架在不同场景下的表现天差地别，只背一个“XXX框架单机百万QPS”的结论去选型，大概率上线就翻车。
这篇文章不站队、不吹某个框架天下第一，而是把我看过的、跑过的、上线扛过流的那些性能数据和选型思路摊开讲。核心回答一个问题：在真实的高并发场景里，性能数据到底怎么用、框架到底怎么选。文章给出的所有对比数据都是我在固定条件下的实测参考值，不是绝对标准，但决策方法和踩坑经验是通用的，适合正在做技术选型、或者准备做架构升级的团队参考。
1. 高并发场景的技术选型难题：先想清楚这三点
1.1 高并发到底拼的是什么：并发模型和执行模型
很多人一提到高并发就想到“每秒多少请求”，但真正懂行的人第一反应是“这个系统的并发模型是什么”。框架的性能上限，本质上由它的并发模型和执行模型决定，编程语言在其中只占一部分比例。
以最常见的HTTP服务为例，传统同步阻塞模型（比如Java早期基于Tomcat的Servlet模型）靠线程池扛并发，每个请求占用一个线程，线程多了以后上下文切换开销和内存开销会迅速吃掉性能。而Go的goroutine模型是协程式调度，几万个并发连接共享少量系统线程，goroutine初始栈只要2KB，内存成本极低。Node.js则是事件循环加非阻塞IO，用单线程处理海量并发IO，IO密集场景下表现很好，但遇到CPU密集型计算就会卡事件循环。Java生态里的响应式编程（WebFlux、Vert.x）走的是和Node.js类似的思路，把阻塞操作改成事件驱动。
这决定了性能数据的第一个解释维度：你在压测工具里看到的QPS，背后是并发模型在特定机器上的物理表现。同样是“读内存再返回”这个最简单的操作，Go因为调度开销低，可以轻松打到很高的QPS；但如果业务里每个请求都要做复杂的计算或者等待下游响应，写法变了，结果又完全不一样。
1.2 绝对性能和有效性能是两回事
我见过不少团队把压测跑到极限，然后拿着那个“极限QPS”去做汇报。问题是线上根本不可能按照压测的理想参数运行——网络有抖动、下游会慢、磁盘会满、GC会出现，所谓极限性能在生产里大概率要打个三到五折。
有效的性能指标，应该是在延迟约束下的吞吐量。这句话的意思是：先定好你能接受的P99延迟是多少（很多业务线定的是200ms以内、99分位不超500ms），然后在这个延迟范围内，看系统能扛住多少QPS。同样是QPS 2万，P99是80ms的系统和P99是500ms的系统，在高并发场景下的表现是两个世界。选型时真正要看的性能数据，不是峰值QPS那一个数字，而是QPS、RT、P99、错误率四个维度放在一起的“性能面”。
这也是为什么任何脱离场景的“XX框架性能对比”都是耍流氓。如果一个压测方案只发了CPU空转的请求、没有模拟真实业务的IO和计算，测出来的数据只能说明框架的底部结构好不好，根本不能说明它适不适合你这个业务。
1.3 性能数据和业务场景要一一对应
技术选型最常见的错误，就是拿一个场景的压测结论套到另一个场景里。我在库存场景踩过一次很深的坑，之后就对“场景对应”这件事特别敏感。
库存扣减类业务，比如ERP里的出库和盘点，它的高并发核心不是“返回一个字符串快不快”，而是“数据库行锁的竞争激烈程度”和“缓存与数据库的一致性保障”。这个场景里，再快的Web框架也没用，瓶颈在存储层和事务层的协调。而IM场景的瓶颈不在存储层，在于大量长连接的内存占用和消息广播的扇出效率，框架本身能不能高效管理几十万连接才是关键。API网关的瓶颈又在连接管理和转发吞吐上，和前面两个场景又不一样。
所以这篇文章里我反复强调“先定义场景，再看性能数据”，数据只有和场景对上才有决策价值。下面的所有框架对比和案例，也都是绑定具体场景来展开的。
2. 性能数据的正确打开方式：测试工具、方法与解读
2.1 压测工具先别急着用，搞清楚它们各自在测什么
高并发压测工具我用过不少，从命令行工具到分布式压测平台都有接触。不同工具测出来的数据口径不完全一致，选型对比时最怕的就是用A工具测框架X、用B工具测框架Y，然后拿两份数据对比——这基本等于无效对比。
我自己最常用的组合是这样：
- wrk：单机、低资源占用、用C写的，适合快速看一个HTTP接口的吞吐和延迟分布。它用多线程加事件驱动模拟并发，几十秒就能出一个直观结果，缺点是脚本能力有限，复杂场景写起来费劲。
- k6：脚本友好，支持HTTP、WebSocket、gRPC这些协议，还能设置阈值做自动断言。我通常在需要跑稍复杂业务场景时用它，可以直接出P95、P99和错误率报告。
- JMeter：老牌工具，插件丰富，多人协作做完整压测流程时好用。缺点是资源占用偏高，单机模拟高并发容易被JVM自身的开销影响数据。
- ghz：专门压gRPC接口的工具。很多微服务内部通信走gRPC，用HTTP工具去压会失真，ghz在这方面比通用工具靠谱。
我的建议是：日常快速验证用wrk，项目级选型对比用k6写统一场景脚本，涉及gRPC加测一批ghz。无论最后选了哪个，务必保证所有被测框架用的是同一套工具、同一份脚本、同一个压测参数，这样出来的数据才有横向对比的意义。
2.2 一套我常用的压测方案模板，直接抄作业
这里分享一个我跑框架对比时固定用的压测方案，照着做基本不会出大错：
第一步，固定环境。机器规格要一致，比如都是4核8G的云主机，CPU型号尽量一致。系统参数方面，把文件描述符上限、TCP连接 backlog、内核网络缓冲区这些调成一样的值。软件层面统一用容器部署，避免宿主机的进程干扰。
第二步，设计场景。普通API场景至少要有三个用例：纯读接口（比如查缓存返回JSON）、纯写接口（比如写入一条记录）、读写混合接口（比如先查再写）。混合操作的比重按实际业务来，没有业务参考就默认7比3（读7写3）。
第三步，预热。正式压测前先用低并发跑1到2分钟，把连接池、线程池、JIT预热做完，否则冷启动的数据忽高忽低。
第四步，阶梯加压。不要直接按1000并发开跑。从50并发开始，依次加100、200、500、1000、2000，每档跑2到3分钟，记录每档的QPS、平均RT、P99、错误率和CPU内存占用。这样能画出完整的能力曲线，也能找到系统的拐点。
第五步，记录完整的测试参数。并发数、Keep-Alive是否开启、超时时间、请求体大小、压测时长全部写清楚。没有这些参数，光写“测出来QPS 5万”这行字是零价值的。
2.3 性能数据解读：QPS和P99要一起看，错误率更是魔鬼
数据跑出来后，解读也有讲究。我最看重的不是峰值QPS，因为峰值往往是资源耗尽前那一刻的回光返照，真正有参考意义的是“稳定QPS”——长时间运行不跌、错误率接近于零的那个区间。
P99说明长尾情况。如果平均RT很漂亮但P99飙到几秒，说明系统里有些请求碰到了严重争抢或者GC停顿，这种抖动在实时性要求高的场景里不可接受。P99和平均值的差距越小，系统越稳定。
错误率是最容易骗人的指标。有的压测工具默认把超时算作错误，有的不算；有的框架连接池满了会直接把请求拒绝掉，表现为错误率上升但RT不高。这个数据一定要结合框架日志和系统监控一起看，别只看面板上那个数字。
再看CPU和内存。两个框架QPS接近的情况下，内存占用低的那个在弹性扩容时优势明显——同样的资源预算可以多扛一倍的连接数。特别是IM这类长连接服务，内存模型几乎决定了上限。
还有一个细节：压测时要监控到“最后一公里”。我习惯在客户端工具之外，再盯着被压机器的网络流入流出、磁盘IO、GC日志。很多时候性能瓶颈根本不在框架本身，而是在机器层面的某个角落。这些监控数据能让性能数据变得立体，而不是屏幕上孤零零的一个数字。
3. 主流框架横向对比：用数据说话
3.1 Go生态实测：Gin和net/http的表现及适用边界
Go在高并发领域现在基本是“标准答案”之一。我压测过Gin和标准库net/http在同样场景下的表现，结果很有意思。
在4核8G机器、1000并发、Keep-Alive开启、返回一个小JSON的纯读场景下，Gin的稳定QPS实测在8万到10万之间，P99大概在120ms到150ms；标准库net/http因为少了路由层的开销，反而还能高出10%到15%。但换成带路径参数、中间件链、日志记录的真实业务场景后，两者的差距缩小到可以忽略，瓶颈很快转移到了业务代码里的数据库访问和序列化。
Gin真正的优势不在“原生性能极限”，而在它的中间件生态和API易用性。gin的Logger、Recovery、CORS、限流中间件都是现成的，团队上手快。但如果是极端性能敏感的场景，比如网关转发，直接基于net/http或者更底层的fasthttp手写精简处理器，反而能再挤出两到三成的吞吐。
Go在高并发下的看家本领还是goroutine。我在IM场景里实测过，一个4核8G的Go进程开gRPC长连接，单机可以稳定维持20万以上的在线连接，每连接的内存开销大概十几KB级别。这个数据在Java和Node生态里很难打到，是Go在高并发IM场景里最强的护城河。
3.2 Java生态实测：Spring WebFlux、Vert.x与传统MVC的差距
Java生态的情况要复杂一些。传统Spring MVC（基于Servlet）的线程池模型在并发上来后，线程数量增多，上下文切换开销飙升，我实测4核8G下大概稳定在2万到3万QPS，内存占用还偏高。这个模型不是不能高并发，而是需要堆机器，扩容成本摆在那里。
响应式编程模型在性能上确实更亮眼。同一台4核8G机器，Spring WebFlux的纯读场景稳定QPS大概在5万到6万，P99比传统MVC更平稳；Vert.x因为是事件总线加无阻塞线程模型，调度更轻量，可以再高一点，在6万到7万之间。但这两个框架都有同一个代价：学习曲线陡、排查问题难度大。异步栈里的异常追踪起来非常难受，很多团队在这上面交了不少学费。
所以Java生态选型我一般这么看：团队熟悉传统Spring、业务事务复杂、并发量在单机2万到3万足够，那就别为了“高并发”这个名头强行上WebFlux，把资源放在缓存和水平扩展上；如果业务本身是网关、推送这类IO密集、事务浅的场景，且团队有人能啃下响应式编程的复杂度，Vert.x和WebFlux的数据优势才值得兑现。
这里还不得不提GC。Java服务在高并发下的性能波动，很多根因在GC停顿上。用G1还是ZGC、堆怎么给，直接影响P99。我压过同一个WebFlux服务在默认G1和调优后的G1下的差距，P99能从200ms差到80ms。性能数据里出现不正常的抖动时，先怀疑GC，再怀疑框架本身。
3.3 Node.js与Python：高并发场景下它们的真实位置
Node.js的并发模型是事件循环加非阻塞IO，代码跑在单线程里。它在轻量IO密集场景下的并发表现其实不差，我在4核8G下用Express压过一个简单的读Redis接口，QPS稳定在3万到4万，P99在200ms以内。同样是这个接口，Fastify因为更轻量，能到5万左右。
但Node的问题很典型：只要业务里出现CPU密集型计算，事件循环就会被阻塞，整个进程的吞吐瞬间崩掉。实测里，在一个请求里加入一段50ms的同步加密计算，Node的QPS直接从几万跌到几千，P99也跟着恶化。所以Node在高并发架构里的正确位置是：BFF层、IO聚合层、轻量API网关这种“薄”服务，不适合做需要大量计算的核心业务。
Python的情况更特殊。FastAPI基于ASGI，在4核8G下纯读场景能跑到1万到1.5万QPS，对于很多内部系统来说完全够用。Python的痛点过去是GIL，多线程在CPU密集场景下基本并行不起来；但如果你用的是IO密集场景，asyncio配合异步驱动，性能也够看。我见过不少数据分析和机器学习服务用Python写，并发量不高但单请求计算复杂，这种情况下硬换成Go反而让编码和维护成本飙升。
所以对Node和Python我的观点是一致的：别拿它们的单机极限去跟Go或者Java比，比不过。但高并发场景不是一个单体框架的独角戏，服务拆分后，边缘服务和数据处理服务用Node/Python完全合理，关键是知道自己用它解决哪一段问题。
3.4 长连接与IM场景：Go的goroutine模型为什么一骑绝尘
IM场景值得单独拿出来说，因为它的高并发形态和前几个完全不同——不是“每秒多少请求”，而是“同时挂多少连接”。
一个IM服务要面对的是几十万甚至上百万的长连接。每一条连接在框架层面都对应一个协程或者线程。Java传统NIO模型虽然能用少量线程管理海量连接，但业务上每条连接的状态和上下文仍要占用不少内存；如果每条连接一个线程，那基本撑不过几千就内存告急。Node.js靠事件循环处理长连接，IO效率高，但在需要推送消息时，如果有大量CPU操作，单线程的扇出效率就会成为瓶颈。
Go在IM场景的优势是结构性优势。goroutine本身极轻，单条连接一个goroutine的编程模型很符合直觉，内存开销又低，再配合channel做读写协程的通信，代码写起来顺畅，性能也很强。实测数据：4核8G的Go进程，单机20万长连接，内存大约占用1.5GB到2GB，消息广播的吞吐可以支撑每秒三五万条消息在连接间扇出，P99保持在100ms内。
Java生态里Netty也能做到类似量级，Netty的性能并不输Go。但Netty的开发复杂度比Go高一个级别，异步回调链或者响应式链的维护成本大。所以纯从IM场景的工程效率出发，Go几乎是我第一推荐。这背后说明一个道理：并发模型契合场景，比语言本身的性能标签更重要。
4. 典型应用场景下的选型决策：从IM到ERP库存
4.1 ERP库存高并发扣减：数据一致性和并发性能怎么取舍
库存扣减是个看着简单、做起来极容易翻车的业务。用户下单扣库存、出库扣库存、盘点调整库存，每个操作都要保证不能超卖，又是典型的高频写操作。这个场景的架构选型，框架本身只是最表层，真正的决策点在“扣减的原子性由谁保证”。
MySQL行级锁是最直接的方案：UPDATE inventory SET stock = stock - 1 WHERE sku_id = ? AND stock > 0。性能实测在4核8G数据库上，单表情况下大概能支撑每秒几千次的扣减，如果业务量级就在这个水平，完全不用折腾。
但一旦涉及热点SKU——比如某个爆款商品被大量用户同时抢购——行锁竞争会迅速拖垮库层。这时候常规解法是引入Redis缓存扣减配合Lua脚本做原子操作：先把库存加载到Redis，扣减在Redis里用一条原子脚本完成，异步落库到MySQL。实测这个方案在Redis单节点上可以稳定跑到每秒3万到5万次扣减操作，瓶颈在Redis不会在业务框架。
需要注意这个方案的代价是架构复杂度上升：缓存与数据库的一致性靠异步补偿，一旦消息积压或者失败，库存数据就会有短暂误差。选型时要接受的现实是，高并发下“强一致”和“高性能”基本不可兼得，必须按业务等级分层处理——核心金额类扣减走数据库强一致，普通抢购类扣减走Redis异步。
从框架角度看，这个场景里Go和Java都能胜任，因为真正的性能瓶颈在Redis和MySQL。反而是框架的生态比较重要：Java有成熟的分布式事务组件（Seata这类），Go在微服务框架里也有不错的分布式锁和消息实现。前提还是团队熟什么用什么，别为了性能把团队逼到不熟悉的语言上。
4.2 高并发IM推送：连接数、消息扇出和内存模型的考验
IM的选型在前面已经说得比较透。这里给出更具体的架构视角。一个IM系统通常包含接入网关（维护长连接）、消息服务（处理消息投递和存储）、推送服务（负责广播和单发）三层。接入网关是高并发压力最大的地方，因为长连接的数量直接由它扛。
如果单机连接数预期在10万以下，Java用Netty或者Go都行，Node.js也勉强可以，主要看团队的运维能力。如果单机连接数预期在20万以上，Go基本是默认选择。我实测过Go编写的WebSocket接入层，配合gorilla/websocket库，单机25万连接时内存占用还能控制在3GB以内，CPU稳定在70%上下，消息推送的P99也能达标。
消息扇出是另一个容易被低估的性能点。一条群消息要推给5000个成员，如果服务端逐个循环发送，扇出延迟会随人数线性上升。高并发IM的推送层一般要引入一层Locker或者消息队列做分片，把扇出任务拆到多台机器上并行推送。框架在这一层的价值有两个：一是连接状态的分布式管理能力（比如注册发现、一致性哈希），二是路由转发的效率。Go在这个领域依然有优势，很多开源的IM参考实现都是用Go写的，可以直接借鉴。
4.3 API网关场景：吞吐量敏感时的框架和中间件选择
网关是高并发架构里最典型的吞吐量敏感场景。它不求业务逻辑复杂，但要对海量请求做快速转发、鉴权、限流、日志记录。网关的并发模型和业务服务完全不一样，瓶颈集中在连接管理和转发路径的效率上。
Nginx和OpenResty是经典选择。OpenResty基于Nginx和Lua，能直接在Nginx层写鉴权和限流逻辑，单机吞吐量极高。实测在4核8G机器上，OpenResty做反向代理转发小请求，稳定QPS可以到10万以上。这个量级在网关入口完全够用。
如果网关需要和业务系统深度集成，比如动态路由来自注册中心、鉴权需要查询业务库，用Go自研网关也很常见。Go的net/http库单机转发吞吐实测和OpenResty差距不大，但胜在业务代码写起来更自由，可以直接集成内部的各种SDK。这里压测数据的意义是给硬件扩容做参考，比如预期流量是每秒2万请求，用OpenResty单机2台就能覆盖，用Go单机可能要3台，这个差距完全可以通过加机器抹平。
网关选型还有一个容易被忽略的性能细节：连接数大于QPS。HTTP Keep-Alive在网关场景会让连接数远高于每秒请求数，连接管理的内存开销决定了网关单机能支撑多少客户端。这也是为什么很多自研网关选择Go——每连接占用的goroutine开销远低于Java线程，网关进程在百万连接下的内存状态完全可控。
5. 选型中常见的五个陷阱和避坑经验
5.1 只盯着单机极限性能，忽略水平扩展的总成本
这是我在很多技术方案评审里看到的问题：一个框架单机QPS高，就认定它“性能好”，选了它，结果上线后发现水平扩展的复杂度远超预期。单机极限只是一道算术题的分子，分母是扩容时带来的运维复杂度、状态同步成本和故障处理难度。
举个例子，某个框架单机可以扛5万QPS，另一个框架单机只能扛2万QPS。如果业务量是4万QPS，前者一台机器就能扛，后者要两台。看起来前者省了机器，但如果前者的无状态化设计不彻底，扩容时要同步内存会话、管理分布式缓存一致性，运维成本可能远高于多买一台机器。
我的建议是：在性能对比表旁边，永远加一列“水平扩展成本评分”。评分项包括：是否容易做无状态化扩缩容、有没有现成的分布式方案、社区有没有成熟的集群部署文档。性能数据只能告诉你“地板有多高”，扩展成本决定了“天花板有多高”。
5.2 压测场景失真：用Hello World级别的接口做选型
用最简单的返回JSON的接口压框架，是技术选型里最普遍的偷懒方式。这种数据看着好看，但和真实业务的差距可能是一个数量级。
真实业务接口里有数据库查询、Redis访问、RPC调用、序列化、日志、限流鉴权，任何一个环节都可能成为瓶颈。框架本身的调度效率可能只占整个请求链路的10%到20%。我压过一个真实业务接口，数据库查询占了60%以上的时间，用Gin和用Netty跑出来的QPS差距不到10%，和它们各自在Hello World压测上的差距完全不成比例。
所以我的做法是：选型对比时，至少把被压接口带上一次真实的数据库查询和一次Redis读取，模拟线上流程的典型链路。如果框架的差异在这种链路下变得很小，那说明真正的瓶颈在下游存储，选型决策应该把重心放到存储选型和缓存设计上，而不是继续纠结用Gin还是用Spring Boot。
5.3 只看峰值数据，忽略长时间运行下的稳定性
压测跑3分钟出的数据和跑30分钟出的数据，差得可能很大。短时间压测暴露不了内存泄漏、连接池耗尽、慢查询累积、GC老年代膨胀这些问题，而这些恰恰是生产环境最容易要命的事情。
我吃过一次教训：某个服务短压测QPS和RT都很漂亮，但线上运行两个小时后P99开始缓慢上升，四个小时后响应时间严重恶化。排查下来是某个底层SDK的线程池配置不合理，长时间运行后任务堆积。这类问题在选型压测阶段如果不拉长时间，根本发现不了。
所以正式选型的压测计划里，一定要加一项“长时间稳定性测试”：用生产预估流量70%的压力连续跑至少30分钟到1小时，持续记录P99、CPU、内存、GC和错误率的变化曲线。看数据有没有随时间变差的趋势，比看绝对峰值重要得多。
5.4 忽略业务特性的数据，只对标网络上的公开Benchmark
网上有很多框架性能对比的排行榜，Benchmark的数据每天更新，看起来特别唬人。但这些榜单大多是在极端优化、代码极简的条件下跑的，真实业务根本不可能达到那个水平。更重要的是，公开Benchmark不可能覆盖你的业务特性。
我见过一个团队因为看到某个框架在排行榜上遥遥领先，就选它来做对外API服务，结果那个框架对长超时请求支持得很差，业务里大量调用外部供应商接口，动辄好几秒的等待，把框架的连接池和线程模型打得稀碎。这个场景里，“能抗高并发短请求”的性能排名毫无参考价值。
业务特性包括请求耗时分布、请求大小、业务读写比例、是否有长连接、是否依赖外部慢服务等。选型压测的方案必须把这些特性设计进去。外部慢服务依赖这点尤其要小心，很多高并发框架的线程模型只适合快请求，一遇到成千上万个慢请求同时挂着就把线程池占满了，性能和体验同时崩盘。
5.5 技术栈匹配和团队梯队比性能数据自身的意义更大
说一个很多技术人不太愿意听的事实：选型里的性能因素，往往只占决策权重的三成左右。剩下七成是团队技术栈、生态成熟度和后期维护成本。
Go再好，如果整个团队都是Java背景，转Go的周期至少要两到三个月，期间生产能力几乎归零，团队还容易写出串行内存模型Bug——这种风险远比性能差距更致命。Java生态再成熟，如果团队没人真正掌握响应式编程，强行上WebFlux，救火的成本和事故率一定让你怀疑人生。
性能数据是必要不充分条件：它能帮你排除掉明显不合适的选项，但最终决策必须把团队现状、生态支持、社区活跃度、招聘难易度都放进去打分。高并发系统拼的是长期迭代和稳定运维的能力，框架只负责其中一段。现在跑得快的框架如果没人维护、没人能改，三五年后它就是全公司的技术债，这个代价远远超过当年性能数据带来的那点优势。
6. 我的选型方法论：一份可直接套用的决策清单
6.1 从业务量级反推性能目标
选型前先算一笔账，别一上来就奔着百万QPS去。我通常按三个量级划分：单机QPS千级、单机QPS万级、单机QPS十万级以上。
千级QPS的场景，几乎任何主流框架都够用，选型标准直接偏向团队熟悉度和开发效率，别在高并发框架上浪费时间。万级QPS是大多数中大型业务的核心区，这个量级下框架差异开始显现，但重点仍然在架构设计和存储层优化上，框架只要不拖后腿就行。十万级以上才是真正拼框架并发模型和资源效率的高压区，这种场景下数量QPS、连接模型、内存占用这些硬指标才成为决策第一优先级。
反推性能目标时，还要把业务的峰值系数算进去。比如日常QPS只有1万，但大促时可能冲到5万，选型就要按5万的能力留出冗余，同时压测数据要看5万到6万的区间表现，而不是还在1万附近洋洋得意。
6.2 性能测试和调研先行，再进入框架选型打分表
具体流程我建议这样：先按上一节的量级计算出目标，再设计一版贴合业务链路的压测方案，把候选框架在同一环境、同一脚本下完整跑一遍。拿到数据后，围绕性能、生态、团队、运维四个维度做打分表，每个维度下设细项，按照业务优先级给权重。
性能维度细项包括：稳定QPS、P99、资源占用、水平扩展能力；生态维度细项包括：社区活跃度、第三方库覆盖、文档质量、团队已有经验；运维维度细项包括：监控链路成熟度、故障排查工具、部署调度便利性。每个细项按1到5分打分，加权求和后排序。
打分表的意义是强制把问题摊到桌面上讨论。技术选型最怕的就是“我觉得XX好”，没有量化依据的讨论到最后一定变成情绪对立。有了打分表，至少能达成一个共识：团队在性能、生态、团队、运维之间的权重判断是否一致。如果这一点无法对齐，那比选哪个框架更值得先讨论清楚。
6.3 先用监控验证再全量切换：上线前最后一道保险
选型压测做得再细致，也替代不了真实流量的检验。我的习惯是：新框架选出来后，先拿一个边缘服务或者低流量服务做生产环境的灰度替换，接上完整的监控体系，跑两到四周再决定是否放大流量。
灰度期间重点看的指标是：真实流量下的P99和压测数据的差距、错误率有没有异常波动、内存和GC特征是否和压测一致、线上告警日志有没有出现压测阶段没见过的异常。很多框架性能问题只在特定流量模型下才会暴露，灰度就是最后一道“花小钱办大事”的保险。
我见过一个团队跳过灰度直接把核心服务切到新框架，上线当天就遇到连接数高于压测预期导致的端口耗尽事故。原因很简单：压测工具模拟的连接模型和线上真实客户端的行为有差异，这个差异只有真实流量能暴露。灰度虽然让上线周期延长，但至少不会让你在大促前一天回滚到凌晨三点。
6.4 最后再分享一个小技巧：把压测脚本和报告当代码资产维护
这是我踩过几次坑之后的习惯改变。很多团队做压测都是一次性的，测完数据存成一个表格扔到网盘里，下次选型时又要重新写脚本、重新压、重新解释一遍。一个框架在不同时间、不同机器、不同脚本下测得的数据差异极大，没有原始脚本和完整参数报告，历史数据基本只是摆设。
我现在会把压测脚本、环境参数、部署配置全部放进代码仓库，每次压测完自动生成带版本号的报告。选型讨论的时候直接提交仓库里的报告链接，数据完全可追溯。这个习惯刚开始有点麻烦，但做多了之后好处特别明显：团队在技术决策上开始基于数据说话，而不是基于某个人对某个框架的个人好感。高并发技术选型本来就应该是一个可复现的工程结论，而不是一场辩论赛的口才比拼。
在实际操作中我的体会是，选型永远没有一步到位的完美答案。一款框架今天性能领先，三五年后生态可能衰败；一个方案当前架构优雅，流量再翻十倍可能就要推翻重来。把性能数据当作决策的依据之一，而不是唯一标准，建设好灰度验证和监控回滚的机制，技术决策就不会变成赌博。这套方法我用了几年，至少在关键时刻，它让我做的每一个选型决定都有据可查、有路可退。
