HTML本身不处理Token认证，真正起作用的是后端签发Token、前端正确携带、后端校验三者配合；JWT通常不直接塞入表单字段，而应通过Authorization头传递，表单中仅限已登录用户敏感操作且需后端注入hidden字段并防CSRF。
HTML 本身不处理 Token 认证，它只是承载表单和脚本的容器；真正起作用的是后端签发 Token + 前端正确携带 + 后端校验三者配合。单独在 HTML 里写个 <input type="hidden"> 不等于完成了认证。
HTML 表单怎么传 JWT Token 给后端
JWT 通常不直接塞进表单字段提交——它不是为表单设计的，而是为 API 请求设计的。但如果你非要在传统表单中用（比如登录页、修改密码页），必须明确两点：Token 从哪来、往哪放。
- Token 必须由后端在渲染页面时注入，比如通过模板变量：
<input type="hidden" name="jwt_token" value="{{ user_token }}">；不能前端 JS 自己生成或读 localStorage 拼接，否则绕过鉴权 - 后端接收时，要从
request.form（Flask）或request.getParameter("jwt_token")（Java）里取值，而不是从Authorizationheader —— 表单 POST 默认不带 header - 这种用法只适合“已登录用户操作敏感表单”的场景（如改邮箱），不适合首次登录；首次登录仍应走账号密码 POST，由后端返回 Token
- 注意 CSRF 风险：如果这个表单没配 CSRF Token，光靠 JWT 并不能防伪造请求；JWT 是身份凭证，不是防跨站请求的工具
为什么 fetch() 提交表单总提示 Token 无效
常见原因是 Token 放错位置，或者前后端对传输方式约定不一致。
- 前端用
fetch()发 JSON，却把 Token 塞进表单 DOM 的 hidden 字段里，又没手动读出来：document.querySelector('input[name="jwt_token"]').value必须显式取值并放进body或headers - 后端期待 Token 在
Authorization: Bearer <token>，但前端却放在 JSON body 里：{ "email": "a@b.c", "jwt_token": "xxx" }→ 后端解析不到，直接判无效 - Token 过期时间短（比如 5 分钟），而页面加载后用户停留太久才提交，
validateToken()返回 false；建议前端在提交前先检查有效期，或用tryRefreshToken()预热 - JWT 签名密钥不一致：前端看到的 Token 是 dev 环境生成的，后端校验用的是 prod 密钥，
JWTVerifier.verify()必然抛SignatureVerificationException
HTML 页面如何判断用户是否已登录（无 JS 时）
纯静态 HTML 没法做实时 Token 校验，但服务端渲染的 HTML 可以根据会话状态决定输出内容。
立即学习“前端免费学习笔记（深入）”；
- 后端（如 Spring Boot Thymeleaf / Flask Jinja2）在渲染 HTML 前，检查当前请求是否携带有效 Token 或 session；若有效，插入欢迎语、退出按钮等；否则渲染登录入口
- 不要依赖前端 JS 去读
localStorage.getItem("token")再 show/hide 元素——用户禁用 JS 或删掉本地存储，UI 就失效了 - 关键动作（如“删除账户”按钮）必须服务端控制：即使 HTML 里渲染了按钮，后端接口仍需校验 Token，不能只信前端是否显示
- 如果真要用纯 HTML + Cookie 实现“自动登录”，得让后端把 Token 存进
HttpOnlyCookie，并在每次请求时自动带上；但这样就退化成 Session 模式，失去 JWT 无状态优势
最易被忽略的一点：Token 的生命周期管理不在 HTML 层，而在路由拦截器或网关层。HTML 页面只负责传递和展示，别试图在 <script> 里解析 JWT payload 判断过期——Base64 解码不可靠，且无法验证签名。该做的事，交给后端 JwtUtil.validateToken() 和前端 Axios 拦截器统一处理。
