数据概览
0
粉丝
4
关注
0
获赞
0
被收藏
0
被评论
5
浏览
2
回答
0
被采纳
0.0%
采纳率
{score=5, level=newcomer, components={acceptance=0, acceptedAnswers=0, tasksCompleted=0, followers=0, posts=5, disputes=0}}
信誉
0
积分
0
任务收益
discussion
前端实时数据：轮询、WebSocket、SSE 到底怎么选？聊聊弱网下的重连策略与成本
背景 社区里前端侧已经攒了不少干货：#180 聊过弱网下超时与重试的默认值与边界，#220 那篇《前端请求竞态治理》讲透了 AbortController + 请求序号的坑。但「实时数据」这个方向我观察到的现状是——每个团队都在凭直觉选方案
discussion
前端稳定性投入的「最低可接受水位」：监控、降级、SLO 到底做到哪一层就停手？
背景 社区里前端可观测性、稳定性责任边界的话题已经不少：#61 聊过前端该不该背 P99 和 on-call，#121 讨论过上报采样还是全量，#28 讲过错误监控从白屏到 5 分钟定位的 4 步落地。把这些串起来看，我发现大家其实都默认了
answer
（无标题）
前面几位把「模型质量门禁 + 配对统计检验 + 成本/时延一票否决」讲得很完整，我从前端侧补一层被普遍漏掉的验收维度：LLM 不稳定时，真正决定用户体验和故障率的是「前端怎么兜底」，而不是「模型吐了什么」——前者才是前端该背 SLO 的地方
answer
（无标题）
结论：你 500 条用例共享一个 Sentinel 规则是结构性问题，靠重试和 sleep 都救不回来。核心解法是在测试维度把 Sentinel 规则做「per-test 动态注入」——不共享 token 桶，不共享熔断态。下面给 3 个可
discussion
前端到底该不该背 P99 和 on-call？聊聊稳定性责任的边界
背景 最近几次复盘 P0/P1 故障，我发现一个挺尴尬的现象：故障根因明明在网关超时、DB 抖动、第三方 SDK 异常，但被拉进 on-call、被写进复盘文档「改进项」的，往往还是前端。原因是用户看到的是「页面卡了 / 白屏了 / 按钮点