required 单独用于 checkbox 不保险，因未勾选时字段不提交、无法防绕过、旧浏览器支持差，须配合 value="on" 和前后端一致的 name；协议链接须真实可达、带安全属性、含版本号；后端必须严格校验字段存在且值为约定字符串（如"on"）；label 必须用 for 关联 input 以保障可访问性。
为什么 required 单独用在 checkbox 上不保险
浏览器对 checkbox 的 required 校验逻辑很特殊：它只在用户勾选后才把字段发出去；如果没勾选，整个字段根本不会出现在提交数据中。这意味着后端收不到 agree_terms 这个键，而不是收到 "agree_terms": "" 或 "false"。光靠 required 拦不住手动构造 POST 请求绕过前端的攻击者。
更麻烦的是，部分旧版 Safari 和某些安卓 WebView 对 required + checkbox 的支持不一致，可能完全不触发校验气泡，用户点了提交却无响应，体验断裂。
- 必须配合
value="on"（或明确约定的值如"1"），确保勾选时提交的是可识别的字符串 -
name值前后端必须严格一致，别写成terms_agreed前端、agree_tos后端 - 不要依赖 JS 拦截
submit事件做校验——会破坏:invalid样式、无障碍读屏识别和原生错误提示
协议链接必须满足哪些硬性条件
法律上，“已阅读并接受”成立的前提是“真能阅读”。纯文本协议名、href="#"、href="#terms" 都不算有效访问路径，等于没提供条款。
链接还必须带 target="_blank" 和 rel="noopener noreferrer"，否则新开页面可通过 window.opener 控制原页，存在安全风险。国内《个人信息保护法》和 GDPR 都把“可验证的告知”作为同意生效的必要条件。
- 链接地址必须真实返回 200 状态码，不能是 404、500 或跳转到登录页
- 协议页需包含明确版本号（如 “v2.3.0，生效日期：2026-07-01”），用于后续争议追溯
- 不要把协议文本塞进
title或data-属性里——屏幕阅读器读不到，也不算“可访问”
后端必须校验哪几个关键点
前端所有限制都可被绕过，服务端才是法律效力的最终守门人。只要后端没校验，整个同意机制就形同虚设。
常见错误是只判断字段是否存在，却不检查值是否为预期字符串。比如用户提交 {"agree_terms": "0"} 或 {"agree_terms": null}，有些后端框架会默认转成布尔 false 就放行，这不符合“主动勾选”要求。
- 请求体里必须存在
agree_terms字段（不能缺失、不能为null） - 字段值必须严格等于
"on"（浏览器默认行为）或你约定的合法值（如"1"、"true"） - 禁止将空字符串、
"false"、"0"、"off"视为有效同意
label 和 id 关联不是可选项
不写 id 和 for，等于放弃可访问性。视障用户依赖屏幕阅读器点击 label 文本来聚焦并切换复选框状态；小屏设备上，没有足够点击热区会导致误操作率飙升。
更实际的问题是：很多团队用 CSS 隐藏原生 input，再用伪元素画个“漂亮勾选框”，但忘了把点击事件转发给真实控件。结果用户点了半天没反应，或者点了没反馈，直接放弃注册。
-
<input>必须有id，<label></label>必须有对应for属性 - 如果用 JS 控制显示/隐藏，确保
click事件最终触发原生input.click() - 别用
display: none隐藏input——屏幕阅读器会跳过它；改用position: absolute; left: -9999px
"on" 的字符串级比对——这两处一松，前面所有努力都白搭。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
