前端监控:别等用户告诉你应用崩了

前端监控:别等用户告诉你应用崩了

毒舌时刻

这代码写得跟网红滤镜似的——仅供参考。

各位前端同行,咱们今天聊聊前端监控。别告诉我你还在等用户截图告诉你应用崩了,那感觉就像等邻居来告诉你你家着火了——能知道,但已经晚了。

为什么你需要前端监控

最近看到一个项目,生产环境崩溃了 3 小时,开发团队却一无所知。我就想问:你是在做应用还是在做猜谜游戏?

反面教材

// 反面教材:没有监控 // components/Checkout.jsx export default function Checkout() { const [loading, setLoading] = useState(false); const handleSubmit = async () => { setLoading(true); try { await api.checkout(); // 成功处理 } catch (error) { // 只在控制台打印错误 console.error('Checkout failed:', error); // 显示错误信息 setError('支付失败'); } finally { setLoading(false); } }; return ( <button onClick={handleSubmit} disabled={loading}> {loading ? '支付中...' : '支付'} </button> ); } // 错误只在控制台,开发团队看不到 // 用户遇到问题只能截图反馈 

毒舌点评:这代码,错误只在控制台,你是在写应用还是在玩捉迷藏?

前端监控的正确姿势

1. 错误监控

// 正确姿势:Sentry 错误监控 // src/utils/errorMonitoring.js import * as Sentry from '@sentry/react'; export function initSentry() { Sentry.init({ dsn: 'YOUR_SENTRY_DSN', integrations: [ new Sentry.BrowserTracing(), new Sentry.Replay() ], tracesSampleRate: 1.0, replaysSessionSampleRate: 0.1 }); } export function captureError(error) { Sentry.captureException(error); } export function captureMessage(message) { Sentry.captureMessage(message); } // 使用 // components/Checkout.jsx import { captureError } from '../utils/errorMonitoring'; const handleSubmit = async () => { try { await api.checkout(); } catch (error) { captureError(error); setError('支付失败'); } }; 

2. 性能监控

// 正确姿势:性能监控 // src/utils/performanceMonitoring.js import { getCLS, getFID, getFCP, getLCP, getTTFB } from 'web-vitals'; export function initPerformanceMonitoring() { getCLS(console.log); getFID(console.log); getFCP(console.log); getLCP(console.log); getTTFB(console.log); } // 集成到 Sentry import * as Sentry from '@sentry/react'; export function sendToSentry({ name, delta, id }) { Sentry.metrics.distribution(name, delta, { tags: { id } }); } getCLS(sendToSentry); getFID(sendToSentry); getLCP(sendToSentry); 

3. 用户行为监控

// 正确姿势:用户行为监控 // src/utils/userMonitoring.js import * as Sentry from '@sentry/react'; export function trackEvent(eventName, data) { Sentry.captureEvent({ message: eventName, extra: data }); } export function trackClick(element, eventName) { element.addEventListener('click', () => { trackEvent(eventName, { timestamp: new Date().toISOString() }); }); } // 使用 // components/Button.jsx import { trackClick } from '../utils/userMonitoring'; export default function Button({ onClick, children }) { const buttonRef = useRef(null); useEffect(() => { if (buttonRef.current) { trackClick(buttonRef.current, 'button_clicked'); } }, []); return ( <button ref={buttonRef} onClick={onClick}> {children} </button> ); } 

毒舌点评:这才叫现代前端,实时监控,问题早发现早解决。

Read more

昨天一口气面了3家前端岗,结果全凉了...

我提前准备了半个月,八股文背得滚瓜烂熟,Vue响应式原理、Event Loop、浏览器缓存策略倒背如流。结果一天三场面试,场场被问懵,面完出来脑子都是嗡嗡的。 先简单交代一下我的情况:5年前端经验,主要技术栈是Vue2/3 + React,做过电商、中后台项目,自认为基础还算扎实。这次想跳槽去个大厂或者中型公司,薪资期望35k左右。结果现实给我狠狠上了一课! 第一场,某二线大厂,一面就挂了。 面试官上来没问八股,直接扔了个场景: “我们有个活动页,双11高峰期预估PV 200万+,页面里有十几个弹窗组件,每个弹窗都有独立的业务逻辑和样式。现在的问题是,首屏加载很慢,用户滚动时卡顿明显。你从工程化、组件设计、渲染优化三个角度,给一套完整的优化方案。” 我当场就有点懵。脑子里想的都是“代码分割、按需加载、虚拟滚动”这些零散的点,但串不成一个完整的方案。面试官追问“弹窗组件怎么设计能减少渲染开销”,我答得磕磕巴巴,最后他礼貌地说“先这样吧”。 第二场,

机场值机柜台辅助:GLM-4.6V-Flash-WEB识别护照与行李标签

机场值机柜台辅助:GLM-4.6V-Flash-WEB识别护照与行李标签 在繁忙的机场值机大厅,旅客排着长队等待办理登机手续——这一幕几乎成了现代出行的“标配”。工作人员需要快速核对护照信息、录入数据、打印登机牌和行李标签,任何一个环节出错都可能导致航班延误或旅客投诉。尤其是在国际航班高峰期,面对不同国家、语言、格式各异的护照和签证材料,人工处理不仅效率低下,还容易因疲劳产生误判。 有没有一种方式,能让系统“看懂”证件内容,并像资深员工一样自动提取关键信息?如今,随着多模态大模型技术的成熟,这个设想正在变为现实。 智谱AI推出的 GLM-4.6V-Flash-WEB 正是为此类高并发、低延迟场景量身打造的一款轻量级视觉语言模型。它不仅能“看见”图像中的文字,更能“理解”这些文字在上下文中的含义,仅凭一张照片和一句自然语言指令,就能精准输出结构化结果。这为机场值机柜台的智能化升级提供了全新的可能性。 模型定位与核心能力 GLM-4.6V-Flash-WEB 是 GLM-V 系列中专为 Web 端和边缘部署优化的版本,属于典型的视觉-语言联合模型(Vision-Language

Spring Boot 中基于 WebClient 的 SSE 流式接口实战

—— 从 Feign 到 WebClient 的一次真实踩坑记录 一、背景:为什么我要做 SSE? 在最近的一个项目中,我负责接入一个 AI 问答服务。 一开始的接口形态非常常规: @PostMapping("/health_manager") public RespBean<HealthManagerQueryDataVO> sendQuery(...) 客户端发请求,服务端等 AI 全部生成完内容,再一次性返回。 问题很快就暴露了: * AI 返回慢(10 秒甚至更久) * 用户页面“卡死”,体验极差 * 其实 AI 是“边生成边返回”的,但我们完全浪费了这个能力 于是,目标就很明确了: 把原有同步接口,改造成支持 SSE(Server-Sent

【DeepSeek R1部署至RK3588】RKLLM转换→板端部署→局域网web浏览

【DeepSeek R1部署至RK3588】RKLLM转换→板端部署→局域网web浏览

本文为DeepSeek R1 7B 以qwen为底座的LLM在瑞芯微RK3588 SoC上的完整部署流程,记录从开发板驱动适配烧录开始,到最终的开发板终端访问模型和局域网web访问模型的完整流程,有不足之处希望大家共同讨论。 文章目录 * 一、项目背景介绍 * 二、所需工具介绍 * 1.硬件工具 * 1.X86 PC虚拟机Ubuntu20.04 * 2. 准备NPU驱动为0.9.8的RK3588开发板 * 2.软件工具 * 三、获取.safetensors模型权重 * 四、safetensors转RKLLM * 1.转换环境搭建 * 2.模型转换 * 五、RKLLM模型板端部署及推理 * 六、集成开源gradio工具实现web访问 一、项目背景介绍 先来介绍下项目背景吧,目前有一个空闲的firefly出厂的搭载瑞芯微RK3588 SoC的arm64开发板,样式如图所示: 博主之前主要进行CV领域的模型的RK开发板部署,对于LLM和VLM的接触并不算多,但现在大模型是趋势所向,并且瑞芯微及时的完成了针对各开源