HTML无法实现成就防刷，仅能提供结构化钩子；防刷必须由JS触发请求并经服务端独立校验，依据session_id、timestamp、IP等后端信号，前端data属性和class仅作标记与样式，不可信。
HTML里没法直接实现成就防刷机制
HTML是纯静态标记语言，不带逻辑、不执行代码、不访问用户行为数据——所谓“HTML标注成就”本身是个伪命题。所有防刷判断必须由JavaScript（前端）或服务端完成，HTML顶多起个占位或标记作用。
常见错误现象：data-achieved="true" 被当成防刷依据；用disabled禁用按钮后仍被绕过提交；靠hidden属性隐藏成就入口却没校验权限。
- HTML只负责呈现，
data-属性可存状态快照，但不可信，必须和服务端一致校验 - 任何成就解锁逻辑（比如点击10次、停留30秒、完成表单）都要在JS中触发，并立刻发请求到后端确认
- 服务端必须独立验证条件（如数据库记录次数、时间戳、session状态），不能信任
data-unlocked="1"这类前端传来的字段
怎么用HTML配合JS做行为异常判定的起点
HTML能做的，是给JS提供清晰、结构化的钩子，让行为采集更稳定。关键不是“防”，而是“可追溯”。比如用户快速连点、非预期顺序操作、DOM节点异常插入，都得靠HTML结构打基础。
- 给可交互元素加唯一
id和语义化data-action，比如data-action="unlock-achievement-tutorial" - 避免用
onclick="xxx()"内联事件，统一用addEventListener监听，方便后续注入防刷逻辑（如节流、埋点、上下文检查） - 对敏感操作（如领取奖励）的按钮，初始设
disabled，JS校验通过后再启用，同时写入data-ready="true"作状态标记 - 不要用
display: none隐藏成就入口，改用aria-hidden="true"+ 后端权限控制，否则爬虫或调试工具一眼可见
常见误用：把HTML class当防刷开关
class="unlocked"或class="cheated"这类写法在审查元素里一目了然，毫无防护力，还容易引发样式与逻辑耦合问题。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- class只管样式，别让它承担业务状态含义；状态变化应由JS驱动，并同步更新
data-属性供后端参考 - 如果真要标记异常，用
data-anomaly="rapid-click"这类只读描述性字段，且仅用于日志上报，不参与权限判断 - 浏览器控制台一行
document.querySelector('.btn').classList.add('unlocked')就能伪造，永远别在服务端解析class名做鉴权
真正有效的防刷依赖哪些后端信号
前端HTML和JS只是入口，最终判定必须落在服务端。HTML能做的，是确保这些信号被准确、完整地上报过去。
- 上报时必带
timestamp（客户端时间）、session_id（服务端颁发）、user_agent（用于设备指纹辅助识别） - 对同一成就的多次请求，服务端要检查
ip、user_id、action_type三元组的频次（如5分钟内最多2次） - 前端可加简单JS校验（如
performance.now()测操作间隔），但结果只作data-client-interval-ms上报，服务端决定是否采信 - 关键动作（如成就发放）必须走POST，且服务端校验CSRF token + 签名，不能靠
GET /award?id=123这种裸路径
复杂点在于：用户行为链路越长（比如“看视频→答题→分享→领奖”），各环节的HTML标记、JS埋点、服务端状态机就必须严格对齐。漏掉一个data-step="3"或一次未上报的event.preventDefault()，就可能让防刷规则失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
