点赞功能被刷怎么限制单个用户每日上限
摘要：# 点赞刷屏？别慌，这几种“土办法”比买高防还管用 前两天，有个做社区的朋友跟我吐槽，说他们新上的“每日最佳”评选，点赞功能差点被玩坏了。有个哥们儿，也不知道是太喜欢某个帖子，还是纯粹想测试系统极限，一晚上用脚本刷了上千个赞。结果第二天一看排行榜，前十名…
点赞刷屏？别慌，这几种“土办法”比买高防还管用
前两天，有个做社区的朋友跟我吐槽，说他们新上的“每日最佳”评选，点赞功能差点被玩坏了。有个哥们儿，也不知道是太喜欢某个帖子，还是纯粹想测试系统极限，一晚上用脚本刷了上千个赞。结果第二天一看排行榜，前十名里有八个都是他“支持”的——这还评个啥劲儿？
这场景你应该不陌生吧？不管是点赞、投票、还是签到领积分，只要是能“刷”的用户行为，总有人想试试系统的底线。今天咱不聊那些动不动就上高防IP、流量清洗的“重型武器”，就说说这种业务逻辑层面的小漏洞，怎么用最轻巧、最省钱的办法给它堵上。
一、先别急着加服务器，问题可能出在“想当然”上
很多开发兄弟第一反应是：“被刷了？那肯定是并发太高，服务器扛不住，加机器加带宽！” 停，打住。
我见过不少站点，真不是被DDoS打垮的，而是被自己“敞开了”的业务逻辑给拖死的。点赞这种操作，本质上就是个高频、低数据量的请求。你如果只在前端做个“已点赞”的灰色按钮，后端不做任何限制——那不就跟超市门口放个无人看管的零钱箱一样吗？全凭用户自觉。
说白了，技术方案的第一步，不是防“坏人”，而是先别把“好人”也当成圣人。 得假设每个用户都可能“手滑”或者“太热情”。
二、限制单个用户？你得先定义清楚“谁”是用户
这是最核心，也最容易踩坑的地方。你说要限制“单个用户”，那这个用户到底是谁？
- 按账号？ 最基础，但也最好绕开。注册个新号才几分钱？成本几乎为零。
- 按IP？ 稍微好点，但也不够用。家庭宽带重启一下路由器，IP可能就变了。更别说现在用手机流量、公司出口IP是同一个的情况，一棍子打死容易误伤。
- 按设备指纹？ 这个就专业点了。通过收集用户浏览器、屏幕分辨率、字体、插件等一堆信息，生成一个唯一标识。但也不是万能的，有些浏览器隐私模式会干扰，而且用户清个Cookie，指纹可能就变了。
我的经验是：别指望单一维度能搞定。 得玩“组合拳”。比如：
- 核心策略：账号+IP绑定限制。 一个账号一天最多点100个赞。同时，同一个IP地址下，所有账号加起来，每天点赞总数不能超过500个。这样，想靠注册海量小号来刷，成本就高了不少，因为IP资源是有限的。
- 辅助策略：关键行为引入验证。 当一个账号在短时间内（比如1分钟）点赞超过20次，或者一个IP下的点赞频率异常高时，下一个点赞操作弹出一个简单的滑动验证码。真用户偶尔遇到一次，能理解；脚本遇到这个，成本就上去了。 这招对防CC攻击的思路其实是一样的——提高攻击者的操作成本。
三、几个立即可用的“土办法”和进阶思路
光说理论没劲，来点能直接抄作业的。
1. 分层计数，设置“软上限”和“硬熔断”
- 软上限： 用户每天点赞的前100次，畅通无阻。从第101次开始，每次点赞的请求处理延迟增加100毫秒（比如用个
sleep函数）。用户几乎无感，但脚本刷赞的效率会直线下降，从一秒刷几百个变成一秒几个。 - 硬熔断： 当监测到某个用户或IP的点赞频率达到一个绝对异常值（比如一秒10次以上），直接触发熔断。接下来5分钟内，来自这个源的所有点赞请求直接返回失败，并在后台记录一条告警日志。这就叫“事出反常必有妖”，先掐断再说。
2. 给“点赞”这个动作加点“重量” 这是我最喜欢的一个思路。别让点赞变得太“廉价”和“轻易”。
- 前端防抖（Debounce）： 用户连续点击点赞按钮时，只触发最后一次操作。防止连点器。
- 后端校验请求上下文： 一个正常的点赞请求，除了点赞的帖子ID，还应该包含用户浏览页面的停留时间、滚动行为等（当然要脱敏处理）。如果一个请求光秃秃地只有点赞ID，频率还贼高，那大概率有问题。
- 关联其他行为： 比如，用户必须点进帖子详情页，停留超过10秒，才能点赞。这能有效过滤掉那些只刷列表页的脚本。
3. 数据要能“回滚”，别怕麻烦
所有用户行为日志，尤其是点赞、投票、积分变动这类，必须打上详细标签并永久留存（至少半年）。别只用个简单的count计数。
万一真的被刷了，你要能根据日志，精准地把异常数据给“扣”回来，把排行榜恢复到正常状态。这个“后悔药”能力，在运营活动里是救命的。我见过太多活动因为被刷，又无法回滚，最后只能尴尬地宣布作废，那才叫真伤。
四、心里有杆秤：安全、体验与成本的平衡
说到底，所有防护都是在做平衡。
- 你验证码搞得太复杂，真实用户嫌烦，跑了。
- 你限制得太死，普通用户觉得不自由，体验差。
- 你完全放开，那就等着被脚本薅秃。
没有一劳永逸的方案。 我的建议是：先上最基础的账号/IP频控，把大门关上。然后，盯着你的监控告警（你肯定有吧？），看攻击者从哪儿撬门。他换IP，你就加强设备指纹；他伪造设备，你就引入更精细的行为分析。
就像家里防盗，你不可能一开始就把墙砌成银行金库。先装个结实的防盗门和监控（基础频控+日志），发现有人老来踩点（告警），你再考虑是不是要加个防盗窗（验证码）或者养条狗（更复杂的风控模型）。
写在最后
限制单个用户点赞，听起来是个小功能，但背后是业务风控的完整思维。它考验的不是你防火墙的带宽有多大，而是你对自家产品用户行为的理解有多深。
今天聊的这些方法，成本可能不到一台高防服务器的零头，但往往能解决80%的“刷量”问题。剩下的20%高级别、有组织的攻击，那才是真正需要祭出“高防IP+WAF+行为分析”全家桶的时候。
所以，如果你的点赞功能还在“裸奔”，看完这篇文章，心里应该有点谱了吧？别等了，先从加一条where user_id = ? and create_time > today()的查询语句开始吧。
行了，就聊这么多。具体代码怎么写，网上教程一堆，关键是思路得先转过来。