前端input的max属性仅作UI提示，无法替代校验；必须结合JS实时拦截、动态库存查询及后端行锁+原子SQL三重防线才能防止超卖。
input number 的 max 属性只是前端提示，不能当校验用
浏览器原生 max 属性（比如 <input type="number" max="10">）只控制 UI 行为：用户点上下箭头到 10 就停了，手动输入超限值也不会阻止提交。它不参与表单验证逻辑，checkValidity() 可能返回 true，提交照样发出去。
真正起作用的得靠 min/max 配合 required 和 step，再加 JS 监听 input 或 change 事件做实时拦截：
- 监听
input事件，在用户每次输入后立刻检查值是否越界，越界就强制设回合法值（比如Math.min(value, stock)） - 同时调用
setCustomValidity()主动标记无效状态，这样form.reportValidity()才会失败 - 别只依赖
blur或submit时校验——用户可能直接按回车提交，跳过失焦
库存动态变化时，必须在提交前重新拉取最新 stock 值
页面加载时读到的库存（比如 data-stock="8"）可能几秒后就变了。下单前不刷新，就可能出现「显示还有 5 件，实际只剩 2 件」的问题。
稳妥做法是在用户点击提交按钮的瞬间，发起一次轻量 API 请求查实时库存：
立即学习“前端免费学习笔记（深入）”；
- 按钮
disabled状态要保持，直到请求返回；避免重复点击 - 如果接口返回
{ available: 3 }，而用户填了5，就立即input.setCustomValidity("库存不足")并聚焦该字段 - 不要把库存判断逻辑全放在后端——前端也得拦，否则用户体验差（等几秒才弹错）
后端校验必须独立存在，且以数据库当前行锁为准
前端所有限制都可绕过。真正防止超卖的只有后端事务 + 行级锁：
- 用
SELECT ... FOR UPDATE（MySQL）或SELECT ... FOR UPDATE SKIP LOCKED（PostgreSQL）锁定商品记录 - 检查
stock >= requested_quantity，不满足则直接拒绝，不走后续扣减 - 扣减动作必须是原子 SQL：
UPDATE items SET stock = stock - ? WHERE id = ? AND stock >= ?，并检查affectedRows === 1 - 别用「先查再更新」两步走——中间可能被其他请求抢占
用户界面要明确区分「显示库存」和「可用购买数」
一个商品标着「库存 12」，但用户只能买 3 件，可能是因限购、预售、或已有人下单未支付占位。这时候光显示原始 stock 会误导。
建议在表单旁加一行小字提示：
可购买数量：<span id="available-qty">3</span>（库存 12，已锁定 9）
这个数字应由后端计算后透出，前端只负责渲染。每次数量变更（包括用户修改 input、切换规格、甚至页面切回来）都应触发一次可用数重算，而不是复用初始值。
库存上限校验不是单点问题，是前后端+数据库三处必须各自守住防线，且彼此对齐语义。漏掉任何一环，就可能从体验问题变成资损事故。
