小程序上线后，最怕什么？最怕用户遇到问题，但你不不知道。用户用着用着卡了、崩了、白屏了，如果他不说，你永远不知道。而一个用户在遇到糟糕体验后，通常的选择是直接关掉，再也不回来。建立性能监控体系，就是让自己比用户先发现问题，在用户投诉之前修复。
为什么需要性能监控
很多小程序团队的性能问题发现路径是这样的：用户反馈 → 客服告知 → 研发排查 → 修复上线。这个链路短则一天，长则一周。一周时间，不知道多少用户已经流失了。
有监控体系的团队，性能问题发现路径变成这样：监控告警 → 研发定位 → 修复上线。用户可能还没感知到问题，团队就已经修完了。这就是主动运维和被动救火的区别。
小程序性能监控有几类指标需要关注：页面性能（加载时间、渲染时间）、接口性能（API响应速度、成功率）、错误监控（JS报错、资源加载失败）、崩溃监控（小程序闪退）。
页面性能监控怎么做
小程序官方提供了Performance面板，可以手动查看页面性能数据。但手动看只适合调试，不适合长期监控。生产环境需要自动化的性能采集。
关键指标：首屏时间（First Screen Time，FST）是用户感知最直接的指标，指页面第一次内容渲染完成的时间。可以通过performance.getPerformance() API获取。还要关注页面切换时间，tabBar切换和普通页面跳转的耗时。
采集时机：首屏时间在onLoad或onShow里延迟100ms后取数据（确保渲染完成）；接口耗时在请求回调里记录；错误在App.onError里统一捕获。
数据上报策略：不能每台设备都实时上报，会产生大量无用数据。建议采用"采样+阈值"的策略：普通用户采样5%，异常用户（出现卡顿或错误）全量上报。同时设置阈值，超过某个耗时或出现某种错误才上报，减少噪音。
接口性能监控
接口是前后端的桥梁，接口慢或接口挂了，页面体验必然差。接口监控的核心是三个指标：响应时间（从发起到接收到数据的完整耗时）、成功率（调用成功占总调用的比例）、错误分布（哪些接口问题最多）。
建议对所有接口做统一封装，在封装层加监控逻辑：记录每个接口的调用时间、成功/失败状态、错误码。同时区分不同业务场景的接口优先级，核心交易类接口的告警要更敏感。
廷云信息做小程序监控时会画一张"接口健康仪表盘"，把核心接口的响应时间和成功率可视化出来，团队成员每天上班第一眼就能看到系统状态。
错误监控与崩溃捕获
JS错误的捕获用App.onError，页面级错误用Page的onError。但onError捕获的是未处理的异常，已经被try-catch处理的错误不会触发。需要在代码里主动埋错误埋点，把关键节点的异常记录下来。
崩溃监控更复杂。小程序闪退的原因很多：内存溢出、版本兼容、低端机型适配问题等。可以通过用户反馈分析崩溃规律，但更可靠的方式是接入微信提供的性能监控服务。
错误信息要记录完整：错误类型、错误消息、堆栈信息、用户操作路径、机型和微信版本。信息不全的错误日志没有定位价值。
告警机制设计
监控数据上了，告警机制也要跟上。建议分级告警：
一级告警（立即处理）：核心功能不可用、崩溃率突然上升、接口成功率低于95%。这类问题直接影响用户体验，需要研发马上响应。
二级告警（当天处理）：接口响应时间超过阈值、错误率小幅上升、页面加载时间变慢。这类问题暂不影响使用，但需要排查和优化。
三级告警（计划处理）：性能指标接近阈值、某个接口错误开始增多。这类问题可以加入版本迭代计划中处理。
告警渠道：重要告警走IM（如企业微信群）和电话双渠道，避免消息被忽略；一般告警走邮件或日报即可。
监控与优化闭环
监控不是为了看数据，是为了驱动优化。每次性能劣化后都要做复盘：根因是什么？下次怎么避免？优化措施落地后还要跟踪效果，确认指标真的改善了。
没有闭环的监控只是数据展示，有闭环的监控才是质量保障体系。