性能测试指标体系详解：从RT、TPS到系统资源与稳定性-北京尧图网络

1. 先立个框架性能指标不是一个点而是一条链路1.1 别急着看数值先回答“这些指标给谁看”我做了这么多年性能测试发现最容易翻车的不是不会压测而是拿到结果不知道该怎么解读。你给领导汇报说TPS有1200、平均响应时间180毫秒领导一拍桌子说很好但上线第二天用户投诉页面转圈——为什么因为指标选错了没对准“用户感受到的那个东西”。性能测试里的指标归根到底是给两类人看的一类关心体验一类关心成本。用户不关心你的CPU是多少核他只关心“这个操作到底卡不卡”开发关心的是“到底哪一段代码慢了、哪个资源被打满了”。所以一开始就要把指标分到不同视角去组织不能混在一起贴截图。我一般把指标体系分成三层层面主要面向核心要回答的问题业务/用户层产品、业务方用户一次完整操作要多久成功没有应用/服务层开发、测试每秒能处理多少事务错误率是多少长尾延迟有多长系统资源层开发、运维、架构CPU/内存/IO是否被打满瓶颈到底在哪一层这三层不是各看各的而是必须能对上账。用户层说响应时间慢了应用层要能拿出TPS和错误率的证据系统资源层则要指出是哪个资源到了上限。指标拆到这个粒度才叫“完整”不然你只是在罗列数字。1.2 响应时间、TPS、资源利用率性能指标的“铁三角”我记得带新人时最爱打一个比方性能指标就像看一个人跑步。响应时间是他的百米成绩决定单次体验TPS是他的步频决定整体产出系统资源利用率则是他的心率和耗氧量决定这套跑法能维持多久。只看百米成绩可能忽略了这是在操场冲刺而非在马拉松后半段只看步频可能忽略了已经气喘吁吁马上要崩。系统也一样TPS很高不一定健康——有可能是靠耗尽线程池、频繁GC、把CPU打到99%换来的一旦流量再涨一点系统直接雪崩。反过来RT很漂亮也不代表能抗压可能只是并发根本没压上去。所以判断一次压测结果正确的姿势是同时拿出三组数据时间维度RT平均值、P90、P99、最大、超时率容量维度TPS、吞吐量、并发处理中的请求数成本维度CPU利用率、内存走势、GC频率、连接池饱和度三者之间还有一种动态关系随着并发升高TPS先涨后平RT前期平稳后期陡增资源利用率逐步走高。那个“TPS不再上涨、RT突然抬头”的位置就是系统的真实容量拐点。后面我还会专门讲这个拐点怎么找它是容量测试的灵魂。2. 应用层核心指标拆解RT、TPS、并发数、错误率逐个说透2.1 响应时间平均值的迷魂汤与百分位数的真相响应时间是最基础的指标但也最容易被“平均”骗。假设某个接口压测了1000次999次都是200毫秒内返回但有一次线程池被某个慢SQL拖住让一个请求等了8秒。这时候平均响应时间被拉高到208毫秒左右看着好像还行但真实情况是有0.1%的用户经历了8秒的白屏这个体验已经足够让用户骂人了。所以看响应时间我几乎不看平均值重点看百分位数P50中位数一半请求快于它一半慢于它反映典型体验。P90我认为这是日常体验容忍线90%的请求要在这个值以内。P99长尾体验分水岭直接反映极端场景下的稳定性。P999用来抓偶发尖刺如果P999明显高出P99一大截基本能断定有间歇性阻塞比如GC停顿、锁等待、连接池排队。在实际操作中JMeter的聚合报告里可以直接勾选百分位统计也可以用CSV日志自行计算。我的习惯是压测时把响应时间按“事务名”分组导出后写段脚本排序取值。举个例子一万个样本排序后第9900个样本的值就是P99。这个数只要比P50大三到五倍就需要警觉了——说明系统并不是“均匀地慢”而是有一定比例请求被明显卡住。2.2 TPS、QPS和吞吐量先把口径对齐再谈数值TPS和QPS可能是性能测试里被滥用最严重的两个词。很多人混着用但严格来说TPS是“事务数/秒”QPS是“查询数/秒”吞吐量在不同场景下又可能是“每秒处理请求数”或“每秒传输字节数”。关键问题是一个事务往往包含多个请求。比如一个“下单”事务脚本里可能先请求登录态校验再请求商品详情最后调用下单接口一共3个HTTP请求。如果TPS是100那实际的QPS至少是300。压测报告中如果只写TPS不说明事务定义别人根本无法复现你的口径。我见过最坑的一次协作A组用“单接口请求数/秒”对外报TPS5000B组用“完整业务流程事务/秒”报TPS800两边的系统其实是同一个但汇报给管理层以后管理层认为A组和B组数据矛盾质询了一整周。后来我们定了统一规则TPS必须基于脚本里定义的事务粒度且必须把事务包含的请求数写进报告备注。否则所有指标都失去可比性。另外要区分“工具侧吞吐量”和“服务端实际处理能力”。JMeter里显示的Throughput是客户端视角的每秒完成请求数如果客户端本身成为瓶颈比如脚本机器CPU打满、带宽不够这个数值就不是服务端真实能力。压测之前先确认压力机资源占用正常这个细节别忽略。2.3 并发用户数一个被大量测试设计带偏的指标“并发用户数”这四个字误解之大排得上性能测试前三。很多人以为100个线程就是100个并发用户其实线程只是“模拟出来的操作者数量”真正衡量系统压力的指标是“同时处于处理中的请求数”或者说服务端同一时刻在处理的活跃请求数。学过排队论的朋友应该知道Little‘s Law系统中并发请求数 TPS × 平均响应时间。举个例子某接口TPS100平均RT200ms0.2秒那么系统内同时处理中的请求大约就是 100 × 0.2 20个。也就是说哪怕压测脚本开了500个线程由于大部分线程在思考时间、延时、等待响应真正砸到服务端的并发压力可能只有20个。这个数字远比“开了多少线程”更能说明系统负载。反推一下如果你想压出“服务端同时存在200个正在处理的请求”在平均RT0.2秒的前提下TPS需要做到 200 ÷ 0.2 1000。那么压测脚本开多少线程合适这不仅取决于目标TPS还取决于脚本单次迭代耗时。通常的做法是先给一个估计值跑一轮看实际TPS和RT再按公式反调线程数。压测不是配好参数就躺平而是要动态校准。我还想多说一句思考时间。JMeter里可以通过Constant Throughput Timer或BeanShell实现思考时间但很多人做接口压测时根本不加思考时间把所有线程都置成“0等待、疯狂点击”。这样压出来的结果代表的是“极端最大压力”不是真实用户行为。如果目标是评估用户体验出了问题不要怪指标不准先看看脚本里的思考时间是否符合真实使用习惯。2.4 错误率必须拆开看的五个类别错误率是最终底线但“错误率0.05%”这句话如果没有说明错误种类等于没说。我习惯把压测中的错误分成五类在断言和统计时全部分开网络层错误连接超时、连接重置、DNS解析失败。这类错误往往在系统过载时批量出现。HTTP状态码错误5xx、4xx。5xx接近“系统自己承认处理不了”4xx则可能是参数问题。断言失败接口返回200但业务结果不对比如下单后订单号为空。这类最容易被忽略也最影响真实业务。超时错误客户端设置了超时阈值请求没在指定时间内返回。这在压测中非常常见是系统接近瓶颈的重要信号。业务规则错误比如库存不足、余额不够。这类不是系统性能问题应作为业务异常排除在性能指标之外否则会污染错误率。统计那一刻我们通常要求总错误率低于0.1%但更严格的做法是分别看“技术错误率”和“业务错误率”。如果技术错误率高于0.1%就要排查服务端是否已经出现明显劣化业务错误率即使高也必须回头确认是否是测试数据问题。2.5 超时与响应时间尖刺平均值看不见的炸弹有一次稳定性压测前3个小时TPS平稳、RT漂亮但从第4小时开始每过30分钟就会出现一次P99从300ms跳到2秒的尖峰平均响应时间只从180ms涨到220ms乍一看完全没问题。后来通过监控时间线对齐发现尖峰出现的时间正好是JVM触发Full GC的时刻。这个案例说明了为什么性能测试不能只看平均数还要看时间序列上的“毛刺”。处理响应时间尖刺的常用指标是“超时率”和“响应时间分布”。压测工具可以统计响应时间超过自定义阈值的请求百分比比如“超过1秒的请求占比”。在JMeter中可以通过Duration Assertion设置阈值把超过阈值的请求单独标记为失败再统计其比例。我的建议是每个关键事务都设置两档阈值一档是“体验容忍线”比如1秒一档是“不可用线”比如3秒。这两档结果一条写进报告能直接回答业务方“到底多少用户被卡了”。3. 系统资源与中间件指标CPU、内存、GC、连接池如何和业务指标对上账3.1 CPU指标利用率不是越高越好还得看是不是“忙得有价值”系统资源指标是性能排查的第二落点。很多人一看CPU利用率到了90%就觉得性能好其实要看这90%花在哪了。CPU时间可以分为用户态、系统态、等待IO、被抢占等几类。用top命令观察时如果waIO等待很高说明CPU在等磁盘或网络返回这种“忙”是虚忙真实瓶颈可能在存储或网络。我一般压测时会同步记录这么几组CPU相关数据CPU总利用率判断还有多少余量。每个处理器的利用率多核架构下可能出现单核打满、其余空闲这时要怀疑热点线程或锁竞争。用户态/系统态比例系统态占比异常高往往和系统调用、上下文切换有关。平均负载load average这个数要和CPU核数一起看负载超过核数意味着有线程在排队另一种角度看就是“并发处理中的任务”超出了CPU的容纳量。有一次排查一个RT突增问题TPS没降CPU也只有40%但load average高达16机器是8核。通过sar和vmstat定位到进程上下文切换次数极高最后揪出是压测脚本里某个函数导致线程频繁sleep和唤醒把内核调度打爆了。所以CPU指标要看“全息图”不能只看一个百分比。3.2 JVM指标Full GC就是长尾RT的头号嫌疑人Java服务做性能测试JVM指标基本是必修课。核心看四块堆内存使用、GC次数、GC耗时、线程状态。命令可以直接用JDK自带的jstat比如jstat -gcutil 12345 1000 10这个命令的意思是对PID 12345的进程每1秒打印一次GC情况共打印10次。输出里的FGC是Full GC次数FGCT是Full GC累计耗时。如果压测过程中FGC快速增长或者单次Full GC耗时超过几百毫秒那意味着用户请求大概率出现明显的停顿——也就是我们在百分位指标里看到的RT尖刺。另外要看的指标还有老年代使用率如果压测后老年代持续上涨回收完又涨那就不能再自欺欺人地说“只是年轻代对象过多”这通常是内存泄漏的前兆。GC吞吐量即“非GC时间/总时间”。低于95%时就要警惕GC已经消耗了过多CPU。线程数Tomcat的当前线程数、忙碌线程数。如果忙碌线程始终等于最大线程数说明线程池已经见底后续请求只能排队RT会加速恶化。3.3 连接池和线程池指标排队开始的那一刻性能就开始劣化线程池和连接池是服务端最容易发生“排队劣化”的地方。Tomcat的默认线程池配置再大也有上限数据库连接池同样如此。当请求到达速率超过连接释放速率队列里就会堆积等待者。我在压测中常监控的指标包括监控对象关键指标异常信号Tomcat线程池当前线程数、忙碌线程数、队列长度忙碌线程接近maxThreads数据库连接池active连接数、空闲连接数、等待获取连接数active接近maxPoolSize持续不降客户端连接池等待连接线程数、连接获取时间等待线程数持续增加消息队列消费速率、堆积数量堆积数量随时间线性增长为什么这些指标重要因为连接池是典型的“临界资源”一旦耗尽后续请求不会立刻失败而是在池子外面排队。排队时间会直接叠加进RT于是表现是TPS不再上涨但RT像坐了火箭一样往上冲。判断是否是连接池瓶颈最简单的办法就是看等待获取连接的线程数量以及单次获取连接耗时。如果这两个指标与请求RT同步上升基本可以锁定问题。3.4 数据库指标慢查询、锁等待、缓存命中率业务系统性能瓶颈大概70%以上最终都能回到数据库。我在压测时数据库机房需要同步盯的指标慢查询数量与耗时打开慢查询日志把压测时段内的慢SQL捞出来。不是所有慢SQL都影响性能但如果在压测高并发时同一类SQL反复出现在慢日志中那它就是主要嫌疑。锁等待事件InnoDB的行锁等待时间、表锁等待次数。压测时最容易出现的是并发更新同一行时产生行锁竞争造成RT被拉高。连接数数据库最大连接数是100或500一旦打满连接池等待时间飙升。这个问题在压测里出现频率极高。缓存命中率Redis这类缓存组件命中率下降意味着大量请求穿透到DBDB压力剧增。从前有一个让我印象特别深的案例接口压测时TPS一直上不去服务端CPU低、连接池空闲、SQL单条很快但RT就是高。后来查到数据库主从延迟严重代码里有“写后读”逻辑每次写完都要等从库同步同步延迟直接加到了接口RT里。这类问题只盯着应用层指标永远找不到必须把数据库指标拉出来对账。这也是我为什么一直强调性能指标一定要覆盖“请求链路经过的每一层”。4. 稳定性与业务可用性指标有些指标要等压测跑完几个小时才看得见4.1 稳定性测试盯三张趋势图短期压测和长期稳定性压测看的指标不一样。短期主要看峰值能力长期则要看变化趋势。我在稳定性测试里默认会盯三张趋势图错误率趋势错误率随时间逐步上升说明系统在持续劣化。RT百分位趋势P99是否随时间缓慢上升即使平均值很平稳。内存曲线堆内存、非堆内存是否单调向上垃圾回收后是否回不到基线。拿内存来说一个典型的模拟场景是系统每处理一笔订单就创建一个对象并存入一个静态Mapkey是订单号value是订单详情。压测一开始内存正常跑两个小时后老年代慢慢上涨Full GC开始变频繁最后OOM。如果你只跑15分钟负载测试这个BUG永远不会暴露。所以稳定性测试的时间长度设定必须能覆盖一个完整的业务周期而不是拍脑袋说“我跑30分钟吧”。如果线上有每小时定时任务那至少跑3到4个小时如果业务有日终对账最好跑完整的一天。时间本身就是一种测试参数。4.2 可用性指标从错误码到“体验达标率”说到可用性很多人本能地想到“系统没有挂”。但业务视角的可用性比这严格得多。我参与过的一个电商类项目把可用性定义为“5秒内完成下单”只要超过5秒就算这个请求体验不可用。也就是说即使接口返回200只要响应耗时超过阈值就会被计入不达标请求。由此可以定义两个关键指标成功率成功响应数 / 总请求数。这个就是常规意义上的技术可用性。响应达标率在目标时限内返回的成功请求数 / 总请求数。这才是体验可用性。计算可用性时常见公式是“可用性 (总时间 - 不可用时间) / 总时间”。压测场景下可以用成功请求占比近似但更严谨的做法是把“错误请求”和“超时请求”都算入不可用时间窗口。假设线上可用性目标是99.9%意味着一年内故障时间不能超过8.76小时折算到单次压测场景能不能容忍0.1%的失败要从业务目标去倒推而不是套一个放之四海皆准的模板。4.3 容量与成本指标性能不只是技术账还是经济账性能测试做到高阶一定会碰到“成本指标”。我做的很多容量规划项目最终落地问题不是“能不能扛住”而是“用多少机器扛住”。单台机器的极限吞吐是多少、峰值流量下的资源消耗曲线长什么样这些都是把技术指标转化为预算数字的依据。成本类指标可以从以下角度提取每实例最大支撑TPS一台应用服务器能跑到多少TPS直接决定扩容倍数。单事务资源消耗一次完整事务平均消耗多少CPU毫秒、占用多少内存增量。带宽消耗与费用大文件下载、视频流场景尤其重要数据量/秒往往比请求数/秒更能体现资源成本。扩容边际收益从1台扩到2台TPS是否接近翻倍如果只提升30%说明系统存在其他瓶颈盲目扩容是浪费钱。这部分的输出对架构决策特别重要。性能测试报告里加一段“容量预估”按峰值流量计算需要几台应用、几台DB、多大的带宽领导做预算时就能直接抄作业。4.4 拐点指标从压力曲线里找系统的三个关键并发点如果你做容量测试最有价值的一张图不是我前面说的任何单一指标而是“并发数-TPS-RT”三条曲线叠在一起的趋势图。通过曲线形态可以清楚找到三个点最佳并发点TPS随并发数同步上升RT基本平稳。这个区间是系统最健康的工作区。最大并发点TPS达到峰值不再随并发增加而上升RT开始抬头。这是系统最大处理能力的临界点。退化并发点TPS反而下降RT急剧恶化错误率上升。系统已经过载进入了“越压越垮”的阶段。找到这三个点之后容量规划的结论基本就成形了日常运行要让负载落在最佳并发点附近峰值流量可以短暂冲击到最大并发点附近但绝不应该长期停留在退化区。很多线上事故之所以发生就是负载长时间处于退化区系统先响应缓慢随后雪崩。性能测试里如果只看最高TPS不看曲线拐点相当于只知道一个人能跑多远却不知道他从哪里开始会受伤。5. 指标落地实操从选定指标到采集再到报警阈值5.1 按测试类型选指标不要一套模板走天下我经常收到类似的测试计划不管什么场景都列“RT、TPS、错误率、CPU”这种做法错倒没错但没有针对性。不同测试类型指标重点完全不同测试类型核心指标辅助指标基准测试RT均值、P50、P99错误率负载测试TPS、RT曲线、资源利用率连接池、GC压力测试最大并发数、退化点、错误率超时率稳定性测试内存趋势、错误率趋势、P99趋势Full GC次数、慢查询数尖峰测试恢复时间、峰值期错误率队列长度、线程数选定指标的时候我习惯先问自己一句“这次测试要回答什么决策问题”如果决策是“版本能不能上线”核心看RT和错误率如果决策是“线上要加几台机器”核心看容量拐点和单实例TPS如果决策是“某模块的缓存到底该不该加”那就得看DB的慢查询和缓存命中率。指标是工具不是目的一切为决策服务。5.2 JMeter里怎么盯指标聚合报告、CSV日志和后端监听器JMeter是目前最常见的压测工具我就以它为例讲讲指标采集。聚合报告Summary Report/聚合报告里会直接给出Average、Median、90% Line、99% Line、Throughput、Error%等字段。很多人截图只截Average和Throughput我把这种做法称为“自废武功”因为最有价值的99% Line就摆在旁边。更规范的做法是勾选“Save Responses to a file”或配置后端监听器把原始样本数据落盘。压测结束后用脚本对CSV日志做二次分析可以算P999、超时率、响应时间分布甚至做时间窗口切片。举一个CSV日志二次分析的简单思路把每个事务的响应时间按秒聚合生成“每秒最大RT”曲线。统计每小时内P99变化判断是否存在劣化趋势。按错误类型拆错误码定位是超时、5xx还是断言失败。命令行压测时我用类似这样的参数jmeter -n -t script.jmx -l result.jtl -e -o report_dir-e -o配合会生成HTML报告里面自带各类指标图表包括响应时间分布、TPS曲线、错误率等。但要注意工具生成的报告只是原始数据可视化不代表结论结论永远需要你自己结合业务去下。5.3 阈值不要拍脑袋两条校准思路性能测试里最常被问的问题是“RT到底要小于多少才算合格”我从来不直接给一个固定数而是用两条思路校准第一以线上历史数据为基准。如果线上日常P99是300ms压测环境如果跑到800ms那么不管绝对数值多漂亮都是劣化。第二以用户可感知的体验目标为基准。对于电商接口用户能明显感知的临界点大约在1秒到2秒超过3秒基本会流失。你可以把目标定为“P95 1sP99 2.5s”。注意这里的数字必须结合业务属性来定不是照抄。查询类接口和下单类接口用户耐心完全不一样。阈值的另一种用途是报警。稳定性测试过程中一旦某个指标超过阈值就自动通知比如P99连续5分钟超过目标值。专业的做法是给指标设置“黄线”和“红线”黄线代表性能劣化预警红线代表已经不可接受。不要只设一个阈值因为单点抖动太常见了很容易误报。5.4 报告里如何“讲指标”三明治结构性能测试报告不是数据堆砌我总结的“三明治”结构可以直接套用第一层结论。开门见山说“系统在XX并发下满足/不满足XX目标”。第二层证据。用P99、TPS、错误率、资源利用率曲线支撑结论图表要带上下界限。第三层归因与建议。如果没达标定位瓶颈在哪一层给出可执行的优化方向。这里再强调一次指标之间要对得上。如果你写“TPS达到2000”那么RT必须是同一时段的数据CPU、内存曲线也得能匹配上。很多人各截各的图、各取各的时段结果就是报告里的数字互相打架——这种报告交上去不仅是浪费还会让整个测试团队的公信力受损。6. 性能测试指标面试高频问题不是背答案而是会推导6.1 TPS高响应时间就一定低吗不一定。这两者受系统排队模型影响。在系统没有达到容量上限前提高并发可以从一定程度上提高TPS但RT通常也会上升只是上升幅度平缓。当系统达到容量上限之后TPS不再增长RT继续上升形成“TPS平台RT陡增”的典型状态。所以面试时如果问“TPS高是不是性能好”正确答案应该是TPS高只能说明系统处理事务的速率高必须结合RT和资源利用率一起判断。6.2 平均响应时间为什么不能单独作为性能指标因为平均值会被极端值拉偏。我给一个直观的例子100个请求中99个耗时0.1秒1个耗时5秒平均值约为0.149秒看起来很好可是有1%的用户等了5秒。P99、P999、最大响应时间和超时率要一起看。这也是性能测试中用百分位数替代平均值的原因。6.3 并发数、线程数、在线用户数是一回事吗完全不同。在线用户数只是“挂着”的人不一定在发请求线程数是压测脚本模拟的操作者数量受思考时间和响应时间影响真正意义上的系统并发数是“同时处理中的请求数”可以用Little‘s Law估算并发数 TPS × 平均响应时间。面试时能写出这个公式并解释清楚基本就说明你理解了并发模型的本质。6.4 如何定位性能瓶颈我的回答永远是“分层定位”。先看业务指标确定哪些请求慢、错误率如何再看系统资源CPU是否打满、内存是否持续增长、IO是否出现等待然后看中间件线程池是否占满、连接池是否耗尽、GC是否异常最后回到代码层慢SQL、锁竞争、超大对象序列化。性能问题极少只在一个点但顺着链路逐层看总能找到首要瓶颈。最忌讳的是看到CPU高就直接说“加机器”高CPU背后的原因可能是死循环、GC线程占满也可能是正常业务打满——先分清楚再开药。6.5 稳定性测试跑多久才够这是一个没有标准答案的问题但判断逻辑是有的至少覆盖一个完整的业务周期和定时任务周期。如果线上每小时有批处理任务稳定性测试至少跑几小时如果有日终任务至少覆盖24小时。判断标准不是时间本身而是趋势指标是否平稳。错误率有没有随时间上升内存有没有单调上涨P99有没有持续恶化只要趋势不对哪怕跑了72小时也不能说通过。我在实际项目中见过太多“跑了24小时、错误率0、内存平稳、看起来全绿”但上线后仍然出问题的情况原因往往是脚本太温和根本没产生足够压力。稳定性测试的负载设计必须让系统保持在一个合理的压力水位上比如峰值的70%到80%否则你测的只是“空闲态稳定性”没什么参考价值。最后说一点我在实操中最深的体会性能测试的指标数量不是越多越好关键是每一层指标都能为下一层判断提供依据。收到一个测试任务别急着开压测脚本先把“这次测试要回答什么问题”写下来再倒推需要哪些指标、用什么工具采集、阈值定多少。这套流程熟练之后你会发现收藏这篇文的意义不是背指标清单而是拿到任何项目都能快速搭出一套能自洽、能说服人的指标体系。

性能测试指标体系详解：从RT、TPS到系统资源与稳定性

相关推荐

PO模式+数据驱动：打造低维护成本的UI自动化测试框架

用LangChain和Playwright构建大模型驱动的测试智能体

西门子Teamcenter仿真体系建设：构建自动驾驶研发数字主线

更多资讯

Flink/PyFlink CSV读写实战：Schema声明与参数配置避坑

LingBot-World 2.0能商用吗？CC BY-NC-SA 4.0许可证解读：14B权重的使用边界与风险清单

响应式实时数据处理：从概念到落地的完整技术链路

基于YOLOv8的路面裂缝检测系统：中英文双版实战

Portabase数据库恢复教程：如何从备份快照快速找回丢失的数据

cosmos-sdk 系统测试入门：从查询、JSON 断言到 Genesis 与交易驱动的状态测试

今日更新

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？