HTML表单提交username、password、captcha至后端，验证全由后端完成：先校验session/Redis中的验证码，再参数化查询数据库比对加密密码，严禁前端存密、SQL拼接验证码或明文传密。
HTML 表单提交账号密码验证码到后端
HTML 本身不能直接连接数据库，它只是个静态页面；所有验证逻辑（比如比对账号密码、检查验证码是否正确）必须由后端完成。前端唯一要做的，是把 username、password、captcha 这三个字段通过表单提交给后端接口。
常见错误现象：405 Method Not Allowed（没配好 POST 路由）、404 Not Found（action 地址写错）、表单没加 method="POST" 导致用 GET 提交敏感信息。
- 表单
action必须指向后端真实存在的接收地址，例如/login -
input的name属性值要和后端解析时用的键名一致，比如后端 expectcaptcha，那就要写<input name="captcha"> - 别在 HTML 里硬编码数据库连接信息或 SQL —— 这种写法一旦被查看源码就全暴露了
后端怎么验证验证码 + 查询数据库
验证码不是存数据库里查的（除非你做持久化存储），而是比对用户提交的值和服务器 session / cache 中存的当前有效值。账号密码才走数据库查询。
典型错误：把验证码也塞进 SQL 查询里，写成 SELECT * FROM users WHERE username=? AND password=? AND captcha=? —— 这完全错了，captcha 不在用户表里，也不该进 SQL。
立即学习“前端免费学习笔记（深入）”；
- 先校验
captcha：从session或 Redis 中取出captcha_code，和表单提交的captcha字符串严格比对（注意大小写、空格） - 验证码通过后，再用
username查数据库，取出对应用户的加密密码（如hashed_password） - 用安全的比对函数验证密码，比如 Python 的
bcrypt.checkpw()，Node.js 的compareSync()，绝不用==或=== - 查库时务必用参数化查询，防止 SQL 注入，例如用
SELECT id, username FROM users WHERE username = ?
验证码生成与存储常见坑
验证码必须服务端生成、服务端验证，客户端只负责展示和提交。图灵测试类验证码（如图片、滑块）本质是“服务端出题 + 客户端答题 + 服务端判卷”。
容易踩的坑：captcha 存在前端 localStorage 里、用时间戳当验证码、生成后没绑定到用户 session、过期时间没设或设太长。
- 生成后立刻存入 session（如
req.session.captcha = 'aB3x'）或 Redis（key 为captcha:session_id，过期设 5 分钟） - 前端显示的验证码图片 URL 必须带唯一标识（比如随机 token），避免浏览器缓存导致多次请求返回同一个图
- 每次刷新验证码，都要更新服务端存储的值，并让旧值失效
- 不要用 Math.random() 直接生成验证码字符串 —— 可预测，不安全；用 crypto 模块生成真随机字符
前后端联调时最常卡住的点
不是逻辑写错，而是通信细节没对齐：字段名拼错、Content-Type 不匹配、跨域没处理、验证码比对前没 trim()、大小写没统一。
典型报错：Cannot read property 'xxx' of undefined（后端没收到字段）、Invalid or expired captcha（时间不同步或没清空旧值）、Password mismatch（前端传的是明文，后端却拿哈希去比）。
- 用浏览器 DevTools 的 Network 面板确认：表单提交的请求体（Request Payload）里确实有
username、password、captcha三个字段，且值非空 - 后端打印接收到的原始 body，别直接信文档或注释，看实际拿到的是什么
- 验证码比对前务必
.trim().toLowerCase()（如果业务允许忽略大小写） - 数据库查不到用户时，别直接返回“用户名错误”，统一返回“账号或密码错误”，防止枚举攻击
事情说清了就结束。真正难的从来不是写几行代码，而是每个环节都得严丝合缝：前端字段名和服务端 key 对得上、验证码生命周期管得住、密码永远不裸奔、错误提示不泄密。
