不能用 disabled 或 hidden 做权限判断依据，因二者仅影响 ui 层面，无法阻止表单提交或隐藏 dom；data-permission 仅为前端标识，无校验效力；权限控制必须依赖后端返回的结构化权限数据，并在服务端逐接口鉴权。
为什么不能用 disabled 或 hidden 做权限判断依据
这两个属性只是 UI 层面的“遮羞布”，浏览器不会因为加了 disabled 就阻止表单字段提交——它根本不会进 FormData；而 hidden 只是 CSS 视觉隐藏，DOM 依然存在、可被 JS 读写、DevTools 一键删掉就恢复。更危险的是，很多团队把 if (el.disabled) 当作权限开关来写逻辑，结果用户改个属性值就能绕过整个校验链。
data-permission 是便签，不是凭证
给按钮加 data-permission="user:delete" 看起来很清晰，但它不参与任何提交、不加密、不签名，纯属前端自说自话。你无法靠它做服务端决策，也不能拿它当缓存 key 去比对权限变更。真正该做的，是让后端在首次响应里返回结构化权限数组，比如：
{ "permissions": ["user:read", "user:edit"], "editable_fields": ["name", "email"] }
然后前端只做一件事：查这个数组，决定是否设置 contentEditable、是否渲染按钮、是否允许 fetch('/api/users', { method: 'DELETE' })。
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
用 dataset 同步状态，但别让它承担校验责任
当你需要批量控制一批元素的编辑态时，dataset 比反复 setAttribute 更干净：
el.dataset.editable = hasPermission('edit_title') ? 'true' : 'false'- 后续 JS 可以统一用
el.dataset.editable === 'true'判断，避免硬编码字符串 - 但注意：
dataset的值必须来自后端权限响应，不能从 localStorage 或 URL 参数读取 - 移动端 Safari 对
contenteditable+dataset组合有光标错位问题，建议加tabindex="0"强制聚焦能力
最易被忽略的点：菜单和 API 权限必须分离校验
一个用户能看到「删除订单」菜单项，不代表他能调用 DELETE /api/orders/{id}。菜单渲染依赖后端返回的 menus 字段，而接口调用必须单独走鉴权中间件——哪怕请求头里带着 JWT，也得在每个路由 handler 里执行 if (!hasPermission(req.user, 'order:delete')) return 403。前端把按钮藏得再深，只要后端没这行判断，curl 一下就全暴露。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
