1. 为什么终端用户视角的性能测试总被做偏性能测试这件事做了十几年我见过太多团队把力气花在了错误的地方。打开一份典型的性能测试报告满眼都是TPS、响应时间P95、并发用户数、吞吐量曲线数据密密麻麻图表花花绿绿看起来非常专业。但你如果问一句“真实用户用起来到底卡不卡”报告里往往找不到答案。这就是终端用户视角缺失的典型症状——我们测了一堆服务器指标却没有测到用户的真实体验。问题的根源在于传统性能测试的度量体系是面向系统的不是面向人的。系统关心的是请求处理速度、资源利用率、连接池够不够用而用户关心的是“我点了这个按钮之后多久能看到结果”“页面滚动的时候会不会一卡一卡的”“提交表单之后转圈圈要转多久”。这两套语言之间有一道巨大的鸿沟很多性能测试工程师终其一生都在系统侧打转从来没有跨过这道鸿沟去看看用户那一端到底发生了什么。我举个很常见的例子。某次一个团队兴冲冲地跟我说他们的接口P95响应时间只有200毫秒性能非常好。结果我让他们在真实的中低端手机上跑一遍完整流程发现用户从点击“提交订单”到看到成功页面整整花了4.8秒。为什么差距这么大因为那200毫秒只是服务端处理时间没有算上网络传输、DNS解析、TLS握手、前端渲染、图片加载、第三方脚本执行这些环节。用户感受到的是端到端的完整耗时而不是你服务端那一段。所以终端用户视角的性能测试核心要做的事情只有一件把度量点从机房搬到用户的手指上。这不是说服务端指标不重要而是说服务端指标只是手段用户体感才是目的。手段和目的不能搞反了。我经常用一个比喻你开一家餐厅后厨出餐速度再快如果服务员端菜慢、桌子没擦干净、空调不制冷客人体验照样差。性能测试也是一样后端再快前端卡顿、网络抖动、设备性能不足用户照样骂娘。这个理念听起来简单但落地的时候会遇到一堆实际问题。比如怎么在测试环境里模拟真实用户的设备性能怎么把前端渲染耗时和服务端耗时拆开怎么定义“用户觉得卡”这件事这些问题的答案就是接下来要展开讲的核心内容。不管你是刚入行的测试工程师还是带团队的技术负责人只要你的产品有真实用户在终端上使用这套思路都用得上。2. 把“体验”翻译成可度量的技术指标2.1 从主观感受到客观数字的映射逻辑“体验”这个词听起来很虚但做性能测试的人必须把它翻译成可度量、可复现、可对比的数字。这个过程我称之为“体验的指标化”。翻译得好不好直接决定了你的性能测试有没有价值。用户说“卡”背后可能对应好几种不同的技术现象。第一种是响应延迟就是操作之后等待结果的时间太长比如点击按钮后3秒才出现反馈。第二种是帧率不足页面滚动或者动画播放的时候画面不流畅一帧一帧地跳。第三种是交互阻塞用户想点某个按钮但点不动因为主线程被某个长任务占住了。第四种是加载等待页面白屏或者骨架屏停留时间过长。这四种现象对应的技术指标完全不同如果你只用“响应时间”一个指标去覆盖肯定会漏掉很多问题。我的做法是建立一个分层指标体系。最上层是用户可感知的体验指标中间层是前端性能指标最下层是服务端和网络指标。三层之间要有清晰的映射关系任何一层的异常都能往上追溯到用户体验的影响。体验层用户感知前端层浏览器/客户端服务端/网络层操作后多久看到反馈首次输入延迟、交互到下一次绘制接口响应时间、服务端处理耗时页面滚动是否流畅帧率、长任务数量、布局偏移资源加载耗时、CDN命中率内容多久可见首次内容绘制、最大内容绘制首字节时间、HTML下载耗时操作是否被阻塞主线程忙碌时间、总阻塞时间接口并发处理能力、队列等待这张表是我在实际项目中反复打磨出来的基本上覆盖了Web端和移动端的大部分场景。你不需要一开始就把所有指标都测全但至少要知道每个用户体验问题对应的是哪一层、哪个指标。这样在排查问题的时候才不会像无头苍蝇一样乱撞。2.2 核心体验指标的选取与计算口径指标选得好不好关键在于口径是否清晰。我见过太多团队在指标定义上含糊其辞导致测试结果没法对比、没法复现。下面挑几个最核心的指标把计算口径说清楚。首次输入延迟衡量的是用户第一次与页面交互时页面响应的延迟。具体来说是从用户按下鼠标或触摸屏幕到浏览器实际开始处理这个事件之间的时间差。这个指标之所以重要是因为它直接对应“我点了之后有没有反应”这个最基础的体验。如果这个值超过100毫秒用户就会感觉到轻微的迟滞超过300毫秒就会明显觉得“点了没反应”。最大内容绘制衡量的是页面主要内容加载完成的时间点。注意这里说的是“主要内容”不是所有内容。浏览器会持续追踪页面上最大的那个内容元素可能是图片、视频、大段文字块当它完成渲染时记录时间。这个指标对应的是用户“什么时候能看到有用的东西”。一般来说2.5秒以内算良好超过4秒就需要优化了。总阻塞时间衡量的是主线程被长任务占住、无法响应用户输入的总时长。长任务的定义是执行时间超过50毫秒的任务。这个指标对应的是“页面是不是卡住了动不了”。我经常用高速公路来类比主线程就是一条单车道长任务就是一辆大卡车占着车道慢慢开后面的车用户操作只能干等着。总阻塞时间就是所有大卡车占道时间的总和。交互到下一次绘制衡量的是用户交互之后页面视觉上完成更新的耗时。这个指标比首次输入延迟更完整因为它不仅包含了事件处理的时间还包含了渲染更新的时间。用户点了一个按钮按钮变色、弹窗出现、列表刷新这一整套视觉变化完成需要多久就是这个指标要回答的问题。这几个指标的计算都需要在真实浏览器环境里通过Performance API采集不能靠服务端日志推算。采集代码本身要尽量轻量避免测量行为本身影响测量结果。我一般会把采集脚本放在页面最前面同步加载确保它能尽早开始记录。2.3 不同终端设备的指标基线差异做终端用户视角的性能测试有一个绕不开的问题设备性能差异巨大。同一套代码在旗舰手机上跑得飞起在三四年前的中低端机上可能卡成幻灯片。如果你只在高配设备上测得出的结论会严重偏离真实用户的体验。我的经验是至少要覆盖三档设备高端当年旗舰、中端主流千元机、低端老旧设备或入门机型。每一档设备的指标基线都不一样不能用同一套阈值去判断。设备档位首次输入延迟基线最大内容绘制基线总阻塞时间基线高端设备50ms1.5s100ms中端设备100ms2.5s200ms低端设备200ms4.0s500ms这张表里的数字不是拍脑袋定的是我在多个项目里通过大量真实设备测试统计出来的经验值。你会发现低端设备的容忍阈值明显更宽这不是说低端设备用户就活该体验差而是说在低端设备上达到同样的绝对指标更难需要投入的优化成本更高。实际项目中我通常会把中端设备的基线作为必须达标的红线高端设备作为优化目标低端设备作为兜底保障。还有一个容易被忽略的点同一档设备在不同网络环境下的表现差异也很大。4G、5G、弱网、WiFi每种网络条件下的指标基线都不同。我一般会单独建一个弱网测试场景用限速工具模拟3G或者更差的网络看看在这种极端条件下用户体验会退化到什么程度。这个场景下测出来的问题往往是最影响用户留存的问题。3. 搭建贴近真实用户的测试环境3.1 设备选型与真机测试的必要性说到测试环境很多团队的第一反应是用模拟器或者云真机平台。模拟器便宜、方便、可批量但它有一个致命缺陷性能特征和真机差距太大。模拟器跑在PC的CPU上性能往往比真实手机好得多而且没有真实设备的散热限制、内存压力、后台进程干扰。你在模拟器上测出来流畅的页面到真机上可能卡得没法用。我的原则是性能测试必须用真机而且要用有代表性的真机。什么叫有代表性不是说你随便找几台手机就行而是要根据你的用户设备分布来选。这个数据可以从应用的埋点统计里拿到看看用户量最大的机型是哪几款然后按比例选取测试设备。真机测试的另一个好处是能捕捉到模拟器上完全看不到的问题。比如某些机型在低电量模式下会主动降频导致CPU性能骤降某些机型的内存管理策略特别激进后台应用容易被杀某些机型的GPU驱动有兼容性问题导致某些CSS动画渲染异常。这些问题只有在真机上才能复现。真机测试也有代价设备采购成本、维护成本、测试执行效率都比模拟器高。所以我的建议是分阶段做日常回归测试可以用云真机平台快速跑一遍发现可疑问题后再用本地真机深入排查。云真机平台虽然也是真机但网络环境和你本地不一样有些问题在云平台上不一定能复现。3.2 网络条件的模拟与控制网络是终端用户体验中最不可控的因素之一。用户可能在地铁里用着时断时续的4G可能在商场里连着信号很差的公共WiFi也可能在电梯里突然掉到2G。你的应用在这些网络条件下表现如何直接决定了用户会不会流失。做网络模拟我一般用两种方式结合。第一种是在测试设备上安装网络限速工具直接控制设备的上下行带宽、延迟、丢包率。这种方式最贴近真实因为限速发生在设备端所有网络请求都会受到影响。第二种是在测试环境里用网络代理工具做限速这种方式更灵活可以针对特定域名或特定接口做限速但不如设备端限速真实。网络场景的设计要有梯度不能只测“好网络”和“坏网络”两种。我通常会把网络条件分成五档理想网络WiFi延迟10ms带宽充足无丢包良好4G延迟50ms左右带宽10Mbps丢包率0.1%一般4G延迟100ms左右带宽5Mbps丢包率0.5%弱网延迟300ms以上带宽1Mbps丢包率2%极弱网延迟500ms以上带宽500Kbps丢包率5%每一档网络条件下都要跑一遍核心用户流程记录体验指标的变化。你会发现有些问题只在特定网络档位才会暴露比如某个接口在弱网下超时重试逻辑有问题导致用户等待时间翻倍。注意网络模拟工具本身也会消耗设备性能在低端设备上做限速测试时要确认工具本身没有成为性能瓶颈。我一般会先在高端设备上验证限速工具的开销确认可以忽略后再用到低端设备上。3.3 测试数据的真实性与多样性测试数据这件事看起来不起眼实际上对性能测试结果影响巨大。我见过太多团队用几条假数据跑性能测试结果上线后被真实数据量打垮。真实用户的数据有几个特点量大、分布不均、有关联关系。比如一个电商应用有的用户只有几个订单有的用户有几百个订单有的商品有几千条评论有的商品一条评论都没有有的用户关注了几十个人有的用户关注了几千个人。这些数据分布特征会直接影响页面渲染性能、接口查询性能、内存占用。我的做法是测试数据必须从生产环境脱敏后导入保持真实的数据分布特征。如果生产数据不能导出那就用数据生成工具按照真实分布规律生成。比如用户订单数服从长尾分布那就不能用均匀分布去生成测试数据。数据量也要有梯度。我一般会准备三套数据小数据量覆盖80%用户的典型场景、中等数据量覆盖15%用户的重度使用场景、大数据量覆盖5%用户的极端场景。性能测试至少要跑中等数据量大数据量作为压力测试的补充。还有一个容易忽略的点测试数据的清理和重置。性能测试往往要反复跑很多轮如果每轮测试之间不清理数据数据会越积越多测试结果会越来越差但你分不清是代码问题还是数据累积问题。所以每轮测试前都要有可靠的数据重置机制。4. 端到端性能数据的采集与拆解4.1 前端性能数据的采集方案前端性能数据的采集核心是用好浏览器提供的Performance API。这套API能拿到非常细粒度的性能数据从导航开始到页面完全加载每个阶段都有对应的时间戳。采集方案我一般分两种实验室采集和真实用户监控。实验室采集是在受控环境下跑自动化脚本采集详细的性能数据适合做版本对比和问题定位。真实用户监控是在生产环境里采集真实用户的性能数据适合做趋势分析和异常告警。两者互补缺一不可。实验室采集的实现方式是在页面里注入采集脚本用PerformanceObserver监听关键性能事件。下面是一个简化的采集代码示例// 采集最大内容绘制 const lcpObserver new PerformanceObserver((list) { const entries list.getEntries(); const lastEntry entries[entries.length - 1]; console.log(LCP:, lastEntry.startTime); }); lcpObserver.observe({ type: largest-contentful-paint, buffered: true }); // 采集首次输入延迟 const fidObserver new PerformanceObserver((list) { const entries list.getEntries(); entries.forEach((entry) { console.log(FID:, entry.processingStart - entry.startTime); }); }); fidObserver.observe({ type: first-input, buffered: true }); // 采集总阻塞时间 let totalBlockingTime 0; const longTaskObserver new PerformanceObserver((list) { const entries list.getEntries(); entries.forEach((entry) { if (entry.duration 50) { totalBlockingTime entry.duration - 50; } }); }); longTaskObserver.observe({ type: longtask, buffered: true });这段代码可以直接放到页面里跑采集到的数据可以上报到监控平台。注意采集脚本本身要尽量轻量不要引入额外的性能开销。我一般会把采集逻辑压缩后内联到HTML里避免额外的网络请求。真实用户监控的采集方案类似但需要考虑采样率、上报时机、数据量控制等问题。采样率一般设置在1%到10%之间太低会导致数据不够代表性太高会影响用户设备性能。上报时机一般选在页面隐藏或者用户离开时用navigator.sendBeacon发送数据避免阻塞页面卸载。4.2 服务端与网络链路的耗时拆解前端采集到的数据只能告诉你“用户等了多久”但没法告诉你“时间花在哪里了”。要定位瓶颈必须把端到端耗时拆解到每个环节。一个完整的请求链路通常包含这些环节DNS解析、TCP连接建立、TLS握手、发送请求、服务端处理、接收响应、浏览器解析渲染。每个环节的耗时都可以通过Performance API拿到const navigationTiming performance.getEntriesByType(navigation)[0]; const timing { dns: navigationTiming.domainLookupEnd - navigationTiming.domainLookupStart, tcp: navigationTiming.connectEnd - navigationTiming.connectStart, tls: navigationTiming.secureConnectionStart 0 ? navigationTiming.connectEnd - navigationTiming.secureConnectionStart : 0, request: navigationTiming.responseStart - navigationTiming.requestStart, response: navigationTiming.responseEnd - navigationTiming.responseStart, domParsing: navigationTiming.domComplete - navigationTiming.domInteractive, total: navigationTiming.loadEventEnd - navigationTiming.startTime };这段代码能帮你把一次页面加载的耗时拆成七八个环节每个环节的耗时一目了然。我经常用这个方法来定位“为什么页面加载慢”的问题。如果DNS耗时占比高说明DNS解析有问题可以考虑用DNS预解析如果TLS握手耗时高说明证书链或者加密套件需要优化如果服务端处理耗时高那就是后端的问题了。服务端耗时的拆解需要后端配合在接口层面埋点记录每个接口的处理时间、数据库查询时间、缓存访问时间、外部服务调用时间。这些数据要和前端采集的数据关联起来才能形成完整的链路视图。我一般会在请求头里带一个trace ID前端采集到的数据和服务端日志通过这个ID关联这样就能精确知道某个用户的某次操作时间到底花在了哪个环节。4.3 数据关联与全链路追踪全链路追踪是终端用户视角性能测试的终极形态。它能把一次用户操作从前端点击到后端数据库查询的完整链路串起来每个环节的耗时都清清楚楚。实现全链路追踪需要几个前提条件统一的trace ID生成和传递机制、各环节的埋点采集、数据的集中存储和关联查询。trace ID一般在前端发起请求时生成通过请求头传递到服务端服务端再传递到下游服务。每个环节在处理请求时把trace ID和耗时信息一起上报到追踪系统。追踪系统的选型要考虑数据量、查询性能、存储成本。小规模场景可以用开源的追踪方案自建大规模场景建议用商业化的APM服务。不管用哪种方案核心是要能回答这几个问题某个用户的某次操作端到端耗时多少耗时主要花在哪个环节这个环节的耗时是否正常和同类型操作相比是快了还是慢了我做过一个项目用户反馈“提交订单特别慢”。用全链路追踪一查发现前端采集到的端到端耗时是4.2秒其中服务端处理只占300毫秒网络传输占500毫秒剩下3.4秒全花在了前端渲染上。进一步拆解发现订单成功页面要加载一个推荐商品列表这个列表的接口返回了200条数据前端渲染这200条数据花了3秒多。问题定位到之后优化方案就很明确了推荐列表改成懒加载首屏只渲染10条剩下的滚动时再加载。改完之后端到端耗时降到了1.1秒。这个案例说明了一个道理没有全链路追踪你根本不知道时间花在哪里了。你可能会去优化服务端接口但服务端本来就不是瓶颈你可能会去优化网络但网络也不是瓶颈。只有把链路拆开看才能找到真正的瓶颈。5. 从数据到洞察体验问题的定位方法5.1 指标异常时的排查路径采集到数据只是第一步从数据里发现问题、定位根因才是真本事。我总结了一套排查路径基本上能覆盖大部分体验问题。第一步是确认异常是否真实。有时候指标异常是采集误差或者环境干扰导致的不是真实问题。比如某次测试发现最大内容绘制突然从2秒涨到了5秒排查后发现是测试设备后台在下载系统更新占用了网络带宽。所以发现异常后第一件事是排除环境干扰在干净环境下复现。第二步是确定异常的范围。是个别设备还是所有设备是特定网络条件还是所有网络是某个页面还是所有页面是首次访问还是再次访问把范围缩小之后问题的方向就清晰多了。第三步是拆解耗时链路。用前面说的全链路追踪方法把端到端耗时拆到每个环节找到耗时最大的那个环节。这一步是关键很多问题拆开一看就明白了。第四步是深入分析瓶颈环节。如果是前端渲染慢就用浏览器的Performance面板录制一段操作看看具体是哪个函数、哪个样式计算、哪个布局操作耗时最长。如果是网络慢就看看是DNS、TCP、TLS还是传输阶段的问题。如果是服务端慢就看看是数据库查询、缓存访问还是外部调用的问题。第五步是验证修复效果。修改之后要重新跑一遍测试确认指标恢复正常并且没有引入新的问题。我一般会做前后对比测试同一套测试用例、同一台设备、同一个网络环境改前改后各跑一遍用数据说话。5.2 常见体验问题的根因分类做了这么多年性能测试我发现体验问题虽然表现各异但根因就那么几类。掌握这些分类能帮你更快地定位问题。资源加载类问题是最常见的。表现为页面加载慢、白屏时间长、图片显示慢。根因通常是资源体积过大、请求数量过多、没有做懒加载、没有用CDN加速、缓存策略不合理。这类问题的优化手段比较成熟压缩资源、合并请求、懒加载、CDN、强缓存。渲染性能类问题表现为页面滚动卡顿、动画不流畅、交互响应慢。根因通常是DOM节点过多、样式计算复杂、布局抖动、长任务阻塞主线程。优化手段包括减少DOM节点、用CSS动画代替JS动画、避免强制同步布局、拆分长任务。网络请求类问题表现为接口响应慢、请求超时、数据加载不出来。根因通常是接口设计不合理、数据库查询慢、没有做缓存、没有做分页、没有做请求合并。优化手段包括接口聚合、数据库索引优化、多级缓存、分页加载、请求合并。内存类问题表现为页面用久了越来越卡、闪退、白屏。根因通常是内存泄漏、大对象没有释放、事件监听没有解绑、定时器没有清理。这类问题比较隐蔽需要用内存快照对比来定位。第三方脚本类问题表现为页面加载被拖慢、主线程被占用。根因通常是第三方统计、广告、客服脚本加载慢或者执行慢。优化手段包括异步加载、延迟加载、设置超时、降级处理。5.3 优先级判断与优化收益评估发现问题之后不可能所有问题都马上修。资源有限必须排优先级。我判断优先级主要看三个维度影响用户量、影响严重程度、修复成本。影响用户量好理解就是这个问题影响了多少比例的用户。影响严重程度要看这个问题对用户体验的损害有多大是“有点慢但还能用”还是“完全用不了”。修复成本包括开发成本、测试成本、上线风险。我一般用一个简单的评分公式来排优先级优先级 影响用户量 × 影响严重程度 ÷ 修复成本。影响用户量和严重程度各分三档高、中、低修复成本也分三档。算出来分数最高的先修。优化收益评估也很重要。有些优化看起来很美但实际收益很小。比如你把某个接口的响应时间从200毫秒优化到了100毫秒但用户端到端耗时是3秒这100毫秒的优化对用户体验几乎没有影响。反过来如果你把前端渲染时间从2秒优化到了500毫秒用户端到端耗时直接从3秒降到了1.5秒这个收益就非常明显。所以优化之前一定要算清楚这个优化能带来多少端到端耗时的降低对用户体验指标比如最大内容绘制、首次输入延迟有多大改善投入产出比划不划算我见过太多团队花大力气优化了一个非瓶颈环节结果用户体验没有任何提升纯属浪费资源。6. 把性能测试融入日常研发流程6.1 性能门禁的设置与落地性能测试如果只在发版前跑一次那它的价值会大打折扣。问题发现得越晚修复成本越高。理想的状态是把性能测试左移融入到日常研发流程里每次代码提交都跑一遍性能门禁。性能门禁的核心是设定阈值超过阈值就阻断合并。阈值的设定要合理太松了起不到作用太紧了会频繁误报导致团队不信任门禁。我一般会先用一段时间收集数据看看当前性能指标的正常波动范围然后取正常范围的上限作为阈值。门禁指标不用太多选三到五个核心指标就够了。比如最大内容绘制、首次输入延迟、总阻塞时间、端到端耗时。每个指标设定一个红线值超过红线就阻断。同时设定一个黄线值超过黄线就告警但不阻断提醒开发者关注。门禁的落地需要CI/CD流水线的支持。每次代码提交后自动触发性能测试测试结果自动对比基线超过阈值自动阻断合并请求。这套流程搭建起来需要一些投入但长期收益很大。我经历过的一个项目引入性能门禁之后线上性能问题减少了70%以上。注意性能门禁的阈值不是一成不变的。随着业务发展和技术栈升级性能基线会变化阈值也要定期review和调整。我一般每季度review一次根据最新的数据调整阈值。6.2 性能回归的自动化对比性能回归测试是日常研发流程里最实用的环节。每次代码变更后自动跑一遍核心场景的性能测试和上一个稳定版本做对比看看有没有性能退化。自动化对比的关键是控制变量。测试设备、网络环境、测试数据、测试脚本都要保持一致否则对比结果没有意义。我一般会维护一套专用的性能测试环境环境配置固定不变每次测试都在这个环境里跑。对比的维度包括端到端耗时、各环节耗时、核心体验指标、资源加载情况。对比结果用表格呈现变化超过一定比例比如10%的指标标红提醒关注。// 性能对比示例 const baseline { lcp: 2100, fid: 85, tbt: 180, totalTime: 3200 }; const current { lcp: 2450, fid: 92, tbt: 210, totalTime: 3600 }; const threshold 0.1; // 10%变化阈值 Object.keys(baseline).forEach(key { const change (current[key] - baseline[key]) / baseline[key]; if (Math.abs(change) threshold) { console.log(${key} 变化 ${(change * 100).toFixed(1)}%需要关注); } });这段代码可以集成到CI流水线里每次测试后自动对比并输出报告。如果发现性能退化可以自动通知相关开发者在合并之前修复。6.3 线上真实用户监控与告警实验室测试再充分也覆盖不了所有真实场景。线上真实用户监控是最后一道防线能发现实验室里发现不了的问题。真实用户监控的采集方案前面已经讲过这里重点说告警。告警规则的设计要平衡灵敏度和误报率。太灵敏了天天告警团队会麻木太迟钝了问题发生了很久才发现。我一般会设置两级告警一级告警是核心指标超过红线比如最大内容绘制P75超过4秒立即通知值班人员。二级告警是核心指标超过黄线比如最大内容绘制P75超过3秒记录到日报里第二天review。告警还要分维度。整体指标告警之外还要按设备档位、网络类型、页面路径、用户地域等维度分别告警。有时候整体指标正常但某个特定维度的指标已经严重恶化了。比如低端设备上的首次输入延迟已经超过500毫秒但整体指标被高端设备拉平了如果不分维度看就发现不了。线上监控数据还能反哺实验室测试。比如线上发现某个机型的渲染性能特别差就可以把这个机型加入到实验室测试设备列表里后续每次性能测试都覆盖这个机型。这样实验室测试就越来越贴近真实用户发现的问题也越来越有价值。7. 一些踩坑之后才明白的经验做终端用户视角的性能测试这些年踩过的坑不少有些教训是用真金白银换来的。挑几个最有代表性的分享一下。第一个坑是过度依赖实验室数据。早期我做性能测试所有结论都来自实验室环境觉得实验室数据干净、可控、可复现。后来发现实验室环境和真实用户环境差距太大了。实验室里用的是高端设备、稳定WiFi、干净的后台真实用户用的是中低端设备、波动的4G、一堆后台应用。实验室里跑出来2秒加载完的页面真实用户可能要等5秒。所以实验室数据只能作为参考真实用户监控才是最终裁判。第二个坑是只看平均值不看分布。平均值会掩盖很多问题。比如平均端到端耗时是2秒看起来还不错但P95是8秒意味着5%的用户要等8秒以上。这5%的用户很可能就是流失的用户。所以看性能数据一定要看分布P50、P75、P90、P95、P99都要看长尾才是问题所在。第三个坑是忽略设备发热降频的影响。手机用久了会发热发热了CPU就会降频性能就会下降。实验室测试通常只跑几分钟设备还没热起来就测完了数据看起来很漂亮。但真实用户可能连续用半小时设备早就降频了体验完全不一样。所以性能测试要跑长时间至少跑15分钟以上看看设备发热后的性能表现。第四个坑是测试数据太干净。前面说过测试数据要真实但实际操作中很容易偷懒用几条假数据跑一遍就完事了。结果上线后真实数据量一上来页面直接卡死。我现在的要求是性能测试必须用脱敏后的生产数据数据量至少覆盖P90用户的场景。第五个坑是只测正常流程不测异常流程。用户网络断了怎么办接口超时了怎么办服务端返回错误了怎么办这些异常场景下的用户体验往往更差但测试的时候很容易被忽略。我现在会专门设计异常场景的性能测试用例比如断网重连、接口超时重试、服务降级确保这些场景下用户不会看到白屏或者无限转圈。第六个坑是性能优化没有闭环。发现问题、定位问题、修复问题、验证效果这是一个完整的闭环。但很多团队做到修复就停了没有验证修复效果也没有监控修复后的线上表现。结果可能问题没修好或者修好了但引入了新问题。我现在要求每个性能优化都必须有前后对比数据并且上线后持续监控一周确认指标确实改善了才算完成。这些经验听起来都是常识但真正做起来的时候很容易因为赶进度、图省事而跳过。性能测试这件事偷懒的代价往往在线上才暴露出来而那时候修复成本已经高得多了。所以我的建议是宁可测试的时候多花点时间也不要等到用户投诉了再手忙脚乱。