HTML 不设计或实现 Design Token，它仅承载服务端生成的 CSRF Token；Design Token 是设计系统中语义化样式变量，通过 CSS 自定义属性或 JS 注入，而 CSRF Token 必须由服务端动态注入表单隐藏字段以确保安全。
HTML 本身不“设计 Token”，它只负责承载和服务端生成的 Token。所谓“Design Token”是设计系统（Design System）里的概念，和防 CSRF 的 csrf_token 完全无关——混淆这两者会导致前端把样式变量当安全凭证用，或后端漏掉真实防护。
为什么在 HTML 里找不到 Design Token 的实现逻辑
Design Token 是设计团队定义的语义化命名变量（比如 color-primary、spacing-md），用于统一视觉风格，最终要靠 CSS 自定义属性（:root { --color-primary: #007bff; }）或 JS 对象注入到运行时。HTML 只是静态容器，无法“生成”或“校验”这类 token。
- Design Token 不参与请求鉴权，也不需要服务端动态注入
- 它不涉及 session、签名、过期、比对等安全环节
- 若你在 HTML 源码里看到类似
<meta name="design-token" content="...">，那只是前端构建流程中写入的配置快照，不是运行时凭证
真正该在 HTML 里处理的是 CSRF Token，不是 Design Token
防跨站请求伪造必须由服务端控制生命周期，HTML 唯一合规做法是渲染时插入隐藏字段：
<form method="POST" action="/transfer"> <input type="hidden" name="csrf_token" value="a1b2c3d4..."> <input name="amount" /> <button type="submit">转账</button> </form>
- 值必须来自服务端模板变量（如
{{ csrf_token }}或@Html.AntiForgeryToken()），不能前端 JS 拼接 - 不能放在
<meta>或data-属性里供 JS 读取后手动塞进表单——这破坏了服务端对提交路径的约束 - 如果用了 PWA 或 Service Worker，要确保 HTML 不被缓存，否则用户可能提交过期 Token
CSRF Token 和 JWT Token 在 HTML 中的共存陷阱
两者都叫 “token”，但职责完全不同：CSRF Token 防伪造请求，JWT Token 用于身份认证。它们在 HTML 中的落点也不同：
立即学习“前端免费学习笔记（深入）”；
- CSRF Token 必须出现在每个敏感表单的
<input type="hidden">中 - JWT 通常存在
HttpOnlyCookie 里，前端 JS 读不到；若存 localStorage，则仅用于 API 请求头（Authorization: Bearer xxx），绝不用于表单提交 - 千万别把 JWT 当 CSRF Token 用——它没绑定会话状态，也无法做恒定时间比对
- 如果后端同时校验两者，注意错误码分离：
401 Unauthorized（JWT 过期）和403 Forbidden（CSRF 失败）不能混为一谈
最易被忽略的一点：CSRF Token 的刷新时机和服务端 session 的续期策略必须对齐。哪怕代码完全正确，只要用户在标签页 A 提交后 session 被服务端更新，标签页 B 里缓存的旧 HTML 表单就必然失败——这不是 bug，是防护生效的表现。
