纯HTML表单提交时，唯一合规方式是服务端渲染时用<input type="hidden">写死用户ID；绝不可依赖JS动态赋值、localStorage或DOM读取，因均可被篡改；后端必须校验认证状态、比对ID一致性及操作权限。
表单提交时如何不依赖JavaScript自动带入用户ID
纯HTML本身无法在提交时“自动添加”动态值，<input type="hidden"> 是唯一合规且可靠的方式。服务器端必须提前把用户ID注入到这个隐藏字段里，否则前端无法凭空生成可信的用户标识。
常见错误是试图用 document.getElementById 或 form.addEventListener 动态赋值——这不仅可能被绕过，还容易因页面加载顺序导致字段为空。真正安全的做法是：服务端渲染时就写死值。
- 后端模板中直接插入（如 Jinja2：
<input type="hidden" name="user_id" value="{{ current_user.id }}">） - 避免使用
value=""空值 + JS 补充，因为 JS 可被禁用或篡改 - 若用前端框架（React/Vue），确保该字段是服务端直出（SSR/SSG），而非客户端计算
为什么不能用 localStorage 或 sessionStorage 存用户ID再读取
浏览器存储里的用户ID极易被用户手动修改，提交时带上它等于放弃身份校验。后端收到 user_id=123 时，必须重新查 session 或 token 并比对权限，绝不能直接信任表单字段。
典型风险场景：
立即学习“前端免费学习笔记（深入）”；
- 用户F12修改
<input name="user_id" value="1">为value="999"，提交越权操作 -
localStorage.setItem('user_id', 'admin')后用 JS 读取填入表单，毫无防护意义 - 即使加了
readonly或disabled，也能被开发者工具绕过
fetch 提交表单时怎么附带用户ID
如果不用原生表单提交（method="POST" + action），而是用 fetch，那就必须显式构造数据。此时用户ID应来自可信上下文（如登录后存的 token payload 或服务端注入的全局变量），而非 DOM 中读取。
示例（假设服务端已把 ID 注入 window.CURRENT_USER_ID）：
const formData = new FormData(document.querySelector('form'));
formData.set('user_id', window.CURRENT_USER_ID);
fetch('/api/submit', {
method: 'POST',
body: formData
});
- 不要从
document.querySelector('[name="user_id"]').value读——该元素可能被篡改 - 若用 JSON 提交，需确保
user_id字段和服务端 session 解析结果一致，否则校验失败 - 注意
FormData不会自动包含disabled字段，但隐藏字段默认会提交
后端收到 user_id 后必须做三件事
前端传来的 user_id 只是线索，不是凭证。漏掉任一环节都可能导致越权。
- 校验当前请求的认证状态（例如 JWT 是否有效、session 是否未过期）
- 比对请求携带的
user_id和认证信息中解析出的 ID 是否一致 - 检查该用户是否有权执行本次操作（例如编辑的订单是否属于他）
最容易被忽略的是第二点：很多项目只校验“有没有登录”，却放行任意 user_id 参数，这就等于把用户ID当成了可写字段。
