表单必填字段为name、email、phone、date、time、guests六项，并需加约束：date设min为当日，guests用type="number"且min="1" max="20"，time用type="time"，email和phone加正则校验；提交按钮需双保险防重复，后端须幂等处理及字段清洗。
表单必须包含哪些必填字段才不会被用户跳过
餐饮预订最常被漏填的是人数和时间，系统默认提交时只校验 required 属性，但光靠它不够——用户可能选了“2025-01-01”这种明显无效的日期，或填了“0人”。所以除了 name、email、phone、date、time、guests 这六个基础字段，还得加约束：
-
date字段必须设min为今天（用 JavaScript 动态写入new Date().toISOString().split('T')[0]，避免用户手动改 HTML 绕过） -
guests用type="number"并设min="1" max="20"，比下拉菜单更少点击，也防输负数 -
time推荐用type="time"而非文本框，iOS 和 Android 都能唤起原生时间选择器，减少格式错误 - 所有
email和phone字段必须加pattern：邮箱用[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$，手机号建议用^1[3-9]\d{9}$（国内）
提交按钮点击后怎么防止重复提交
用户手快连点两次，后端可能收到两条相同预订。不能只靠前端禁用按钮——万一 JS 加载失败或被禁用就失效。得双保险：
- 按钮初始加
disabled属性，JS 初始化时移除；点击后立即设button.disabled = true，同时把文字改成提交中... - 表单
submit事件里调用event.preventDefault()，再用fetch()发 POST 请求，成功后清空表单并弹提示 - 关键：后端接口必须做幂等处理，比如用
reservation_id（由前端生成 UUID）作为请求唯一标识，重复 ID 直接返回 200 不新建记录
移动端日期/时间选择器适配要点
iOS 的 input[type="date"] 默认显示年月日，但不支持 step 控制最小单位；Android Chrome 则对 min 响应更严格。实际测试发现两个坑：
- iPhone Safari 对
input[type="time"]的step="900"（15 分钟粒度）完全无视，只能靠 JS 后续校验并修正为最近的 15 分钟倍数（如用户选 18:07 → 自动改为 18:00） - 部分安卓机在横屏时日期选择器会遮挡输入框，解决方法是给
input加style="width: 100%; padding: 12px;"，并确保父容器有min-height: 44px（触控最小尺寸） - 别用第三方 picker 库（如 flatpickr），它们在微信内置浏览器里常触发白屏，原生
input兼容性反而更好
后端接收时容易忽略的字段清洗点
前端校验只是第一道关，后端收到数据后仍要重验，尤其注意这些细节：
立即学习“前端免费学习笔记（深入）”；
-
date字段传过来可能是字符串"2025-01-01"，但数据库存的是 DATE 类型，需用strtotime()（PHP）或datetime.fromisoformat()（Python）转成标准格式，否则 MySQL 可能存成0000-00-00 -
time若带秒（如"19:30:00"），而餐厅只按半小时分段，得截断或四舍五入：substr($time, 0, 5)或time[:5] -
guests是数字字符串，必须用intval()或int()强转，防止恶意传"1' OR '1'='1"这类注入内容混在数字里 - 用户可能粘贴带空格的手机号，比如
"138 1234 5678"，后端要用str_replace([' ', '-', '(', ')'], '', $phone)清洗后再验证长度
真正麻烦的不是写表单，是让日期、人数、电话这三样东西在 iOS、安卓、微信、桌面 Chrome 上都按预期工作——每个平台对 input 的渲染逻辑差得挺远，测一遍至少得打开四个真机。
