|

秒杀怎么防机器人：验证码之外的几道防线 限量秒杀场景有个普遍现象：活动开始不到一秒就售罄，而正常用户的请求往往一两秒后才到达——抢到的大多是脚本，请求特征高度一致、时间戳精确到毫秒、操作路径和真人完全不同。 「我们有验证码」挡不住这件事：打

防薅羊毛怎么做：号码风控、设备指纹与分层策略 拉新活动的经典剧本：新注册送无门槛券，上线后领取量涨得飞快——然后一看数据，手机号段高度集中、激活率接近零，全是接码平台的虚拟号，从来没人真正打开过 App。 --- 薅羊毛的常见路径 虚拟号注

接口限流怎么选：固定窗口、滑动窗口、令牌桶 接口被脚本刷是迟早会遇到的事：同一个 userid 高频密集请求同一个接口，间隔均匀，典型的自动化特征。 没有限流的接口，这些请求会全部打到数据库上，慢查询堆积、正常请求跟着遭殃。 --- 固定窗

批量打包下载怎么设计：流式 ZIP 与异步任务 批量打包下载的典型需求：用户勾选几百个文件，后端打成一个 ZIP 返回。 最直觉的实现是把文件全部读进内存再压缩：200 个文件平均 1MB，就是 200MB 堆内存——并发 10 个用户同时

图片处理怎么做：异步处理与 CDN 实时参数 「用户上传的原图太大，页面加载慢，压缩一下」——这个需求最直觉的做法是在上传接口里同步压缩。 但图片压缩是 CPU 密集型操作，量一上来，接口响应时间飙升、线程池被占满，其他接口跟着超时。它不能

大文件上传怎么设计：分片、断点续传、秒传 大文件上传（比如 2GB 的视频），浏览器直接整包 POST 的结果几乎注定：传到一半超时断掉，从头再来，再断。 做大文件上传之前，要明确三件事：分片、断点续传、秒传。三件事不是一件事，实现复杂度逐

报表可重跑的设计：快照、水位线与幂等 「同一张报表，昨天跑出来的数和今天重跑的不一样」——这类问题的原因通常不是计算 bug，而是两次计算之间有数据补录了进来：报表第一次跑的时候这批数据还不在，重跑就多了。 这暴露的是设计问题：报表要不要支

UV 统计为什么有误差：精确计数与近似计数怎么选 「实时看板的 UV 和数仓算出来的对不上」——这是数据统计里最高频的疑问之一。 这不一定是计算错了，而是 UV 本来就分两种做法，精度不同。 --- PV 和 UV 的区别 PV（Page

大数据量导出怎么做：流式写入与异步任务 大数据量导出的经典翻车路径：本地测几十条没问题，一到线上的真实数据量，内存飙升直至 OOM。 问题几乎都出在同一种写法上： 三份数据同时在内存里。10 万行，每行几十个字段，几百 MB 起步。 ---

排行榜的两类需求，难度差了一个数量级 "做个排行榜"——产品说完这句话，你要先问清楚两件事： 一是展示前 N 名的列表，还是要显示用户自己的排名？ 前 N 名列表很好做，自己的排名是另一个问题。 二是用户量级是多少？ 几万和几千万，实现完全