表单提交前怎么判断当前用户有没有权限
权限控制不能只靠前端，但表单提交前做一次快速校验能避免无效请求和糟糕的用户体验。关键不是“拦住所有操作”，而是“提前反馈”。document.querySelector 拿到表单后，检查它是否带有 data-required-role 属性，再比对当前用户角色（通常从全局变量或 sessionStorage 读取）：
const form = document.querySelector('form[data-required-role]');
if (form) {
const requiredRole = form.dataset.requiredRole;
const currentUserRole = sessionStorage.getItem('userRole') || 'guest';
if (!['admin', 'editor'].includes(currentUserRole) && requiredRole === 'admin') {
form.dispatchEvent(new Event('permission-denied'));
alert('你没有权限执行此操作');
form.disabled = true;
}
}
- 别把角色判断逻辑写死在每个表单里，抽成
checkFormPermission(form)函数复用 -
data-required-role值建议用小写、无空格字符串（如editor），避免 JSON 解析或大小写误判 - 这个检查只防手滑，不防篡改——服务端必须重复校验，否则等于没控
按钮禁用状态怎么同步权限变化
用户登录后切换角色（比如从普通成员升为管理员），页面没刷新，但表单按钮状态得立刻更新。靠监听事件比轮询靠谱：
window.addEventListener('role-updated', (e) => {
const buttons = document.querySelectorAll('form button[type="submit"][data-role-scoped]');
buttons.forEach(btn => {
const required = btn.dataset.requiredRole;
const has = userHasRole(required);
btn.disabled = !has;
});
});
- 触发
role-updated的时机：登录成功后、调用权限变更 API 后、JWT token 刷新后 -
userHasRole()应该读取最新权限数据，而不是缓存旧值；建议封装成函数，内部优先查localStorage或authStore - 别用
display: none隐藏按钮——它绕过可访问性检测，也容易让测试遗漏权限路径
隐藏字段被篡改怎么办
很多人用 传权限标识，这是典型误区。浏览器开发者工具两秒就能改掉，后端若直接信任这个值，权限就形同虚设。
- 所有权限相关字段（如
user_role、can_delete）都不该由前端生成或提交 - 如果表单需要携带上下文（比如编辑某条记录），只传不可伪造的标识，如
record_id，权限判定全交给后端查数据库或策略引擎 - 前端可以渲染不同字段（比如管理员看到额外的
is_pinned开关），但这些字段名和值本身不应参与权限决策
服务端返回 403 时前端怎么友好处理
表单提交后服务端拒绝，前端收到 403 Forbidden，这时候弹个“权限不足”就完事？不够。用户可能根本不知道自己缺哪个角色，或者以为是网络问题。
- 后端响应体里加一个
required_role字段（如{"error": "forbidden", "required_role": "admin"}），前端提取后提示：“需要管理员权限才能执行此操作” - 不要只在
catch里统一提示，而是在fetch().then(res => { if (!res.ok) {...} })显式处理403 - 如果用户频繁遇到 403，考虑在错误提示旁加个
，而不是让他去翻文档
权限控制最麻烦的地方不在代码怎么写，而在「谁决定某个表单该由谁操作」这件事本身——它往往跨系统、依赖组织架构变动、还常被临时绕过。前端做的所有检查，本质是给用户一个及时反馈，而不是替代后端的守门人角色。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
