纯HTML无法实现真实好友助力，因其仅负责静态展示，不支持身份校验、网络请求与状态持久化；真实助力必须由后端鉴权接口、前端JavaScript安全调用及数据库唯一约束协同完成。
HTML 本身不能实现好友助力逻辑，它只是静态结构层；真正的“助力”必须靠后端接口 + 前端 JavaScript 驱动，否则所有操作都可被伪造、无法校验身份、无法防刷。
为什么纯 HTML 页面做不了真实助力
HTML 是只负责展示的标记语言，不处理用户身份、不发起网络请求、不校验助力关系。如果你看到一个“点击助力”按钮在纯 HTML 里就变灰+加1，那只是前端模拟，后端根本没记录，数据一刷新就归零。
-
localStorage或sessionStorage存的助力数：换浏览器、清缓存就丢，且无法区分 A 助力了 B 还是 B 助力了 A - 用
GET请求直接调后端接口（如/api/help?from=1001&to=1002）：没签名、没 token、没 referer 校验，爬虫批量刷几万次毫无压力 - 把用户 openid 或手机号写死在 HTML 源码里：严重泄露隐私，还可能被恶意构造请求冒充他人
必须配合的三个关键环节
一个可用的助力活动页面，HTML 只是载体，真正起作用的是以下三部分协同：
-
后端提供带鉴权的助力接口：例如
POST /api/v1/help，要求携带Authorizationheader（JWT 或 sessionid）、from_user_id和to_user_id，并校验二者是否未互助力过、是否在活动时间内、是否满足助力频次限制 -
前端 JS 获取当前用户身份并发起请求：不能硬编码 ID，要通过 SDK（如微信
wx.login+code2Session）或登录态 cookie 安全获取user_id -
HTML 页面承载交互与状态反馈：用
data-*属性存目标用户 ID（如data-target-id="8892"），按钮绑定onclick="doHelp(this)"，成功后更新data-help-count并禁用按钮
防刷和体验细节最容易翻车的地方
很多团队卡在“能跑通”但上线就被刷爆，问题往往出在边界没控住：
立即学习“前端免费学习笔记（深入）”；
- 没做
same-site+csrf_token校验：攻击者诱导用户点击恶意链接即可完成助力 - 助力成功后没清本地缓存或重置按钮状态：用户反复点，前端以为成功了，其实后端已返回
403（重复助力） - 错误提示只写
alert("助力失败")：不展示具体原因（如“你已助力过该好友”或“今日助力次数用尽”），运营排查时两眼一抹黑 - 用
location.href跳转代替fetch：导致页面刷新丢失上下文，用户看不到实时变化，也难做 loading 状态
最常被忽略的一点：助力关系必须落库并建立唯一索引，比如在 MySQL 中建联合唯一键 UNIQUE KEY `uid_aid` (`from_user_id`, `to_user_id`) —— 不然并发请求下，两个几乎同时的助力可能都写入成功，变成双计数。
