前端权限校验仅为体验优化，必须由后端驱动；submit事件中需主动调用hasPermission()等函数校验操作权限，失败时preventDefault()并提示，禁用或隐藏等DOM控制可被绕过，不可替代接口级权限判断。
前端无法独立完成角色权限校验，必须由后端驱动；所有前端控制（包括按钮禁用、字段隐藏）都只是体验层优化，不能替代接口级权限判断。
submit 事件里怎么校验用户有没有操作权限
不能只靠 disabled 或 hidden 属性拦住用户——这些都能被开发者工具删掉。真正该做的是在表单提交时，用 JS 主动检查权限，并决定是否放行：
- 从可信来源（如后端注入的 JSON 脚本或 API 响应）读取用户角色和权限映射表，例如
rolePermissions = { editor: ['post:edit'], admin: ['post:delete'] } - 在
form.addEventListener('submit', ...)中调用权限函数，比如hasPermission('post:delete') - 若返回
false，立即执行e.preventDefault()，并显示明确提示：“无删除权限” - 不要依赖
document.getElementById('btn').disabled的状态来判断——用户可能已手动启用它
为什么不能把权限逻辑写死在 HTML 属性里
像 data-required-permission="post:publish" 这种写法本身没问题，但容易误以为“加了属性就安全了”。问题在于：
- 这个属性值不会自动触发校验，必须配 JS 主动读取和判断
- 如果权限判断逻辑放在前端（比如硬编码
if (user.role === 'admin') {...}），攻击者改个 localStorage 就能绕过 - 多角色场景下，
user.roles = ['editor', 'reviewer']需要查映射表才能知道是否拥有post:publish，这一步必须可复用、不可绕过 - DOM 层面的属性可以被任意篡改，它只适合做标记，不是执行依据
后端验证必须检查三件事，缺一不可
表单提交到 /api/posts/update 这类接口时，后端必须同步确认：
立即学习“前端免费学习笔记（深入）”；
- 请求携带有效的身份凭证（
Authorizationheader、session cookie 或 JWT） - 凭证解析出的用户角色，确实在数据库中存在且未被冻结
- 本次请求的操作（如修改
status字段为published）属于该角色被授权的权限项，而不是仅校验“已登录”或“是编辑”这种粗粒度条件
常见翻车点是：前端渲染时隐藏了“发布”按钮，后端却没校验 status 变更权限，导致用户抓包重放一个带 "status":"published" 的请求就成功了。
字段级编辑权限怎么防绕过
用户可能通过开发者工具给原本 readonly 的 <input> 删除属性，再填入非法值。应对方式是：
- 前端用
readonly或disabled提供视觉反馈，但不依赖它阻止提交 - 后端接收数据后，先比对本次请求中哪些字段被提交了，再查该用户对每个字段是否有编辑权
- 例如普通编辑者提交了
{ title: "...", published_at: "2026-09-01" }，但其权限不允许改published_at，后端应直接忽略该字段，或报错拒绝整条请求 - 敏感字段（如
is_admin、balance）建议后端完全不接收，而由服务端根据上下文生成
最易被忽略的是：权限校验必须基于每次请求实时计算，不能缓存角色数组后长期复用——角色变更（如管理员临时降权）必须立刻生效。
