html本身不能做数据权限控制，真正起作用的是后端在查询时就过滤数据，如sql中添加where creator_id = ?，确保返回的json不包含用户无权查看的行或字段，前端仅依据后端提供的权限标记（如editable、actions）动态渲染ui。
HTML本身不能做数据权限控制——所有在HTML里写的 display: none、v-if、ngIf 或隐藏字段，都拦不住直接改DOM或调API的用户。真正在起作用的，是后端返回的数据本身是否包含某条记录、某个字段、某个操作按钮。
后端必须过滤数据，而不是前端“藏起来”
用户看到的表格行数、字段内容、操作按钮，都该由后端在查询时就决定好。比如一个订单列表接口 GET /api/orders，后端不能返回全部订单再让前端用JavaScript筛出“自己创建的”，而应该在SQL里加 WHERE creator_id = ? 或 WHERE dept_id IN (SELECT dept_id FROM user_depts WHERE user_id = ?)。
- 常见错误：前端收到100条订单，却只渲染其中5条，并以为“权限控制完成了”
- 风险点：用户打开浏览器控制台，执行
console.log(window.orders)就能看到全部原始数据 - 正确做法：后端返回的JSON里，压根不包含用户无权查看的字段（如
price、customer_phone），也不包含无权访问的行 - 性能影响：减少传输量，降低前端渲染压力；避免前端做复杂过滤逻辑
前端如何安全地配合展示权限状态
前端拿到后端返回的数据后，可基于附带的权限标记做 UI 层适配，但所有判断依据必须来自后端响应，而非 localStorage 或硬编码角色。
- 后端应在响应中提供明确字段，例如：
{"id": 123, "status": "draft", "editable": false, "actions": ["view"]} - 前端用这些字段控制按钮显隐：
v-if="row.actions.includes('edit')"，而不是v-if="userRole === 'admin'" - 列级控制同理：后端只返回用户有权看的列，前端模板不写“万一有权限才显示”的兜底逻辑
- 避免把权限逻辑耦合进 HTML 结构，比如
<button v-if="row.creator_id === currentUser.id">删除</button>—— 这类 ID 比对容易被绕过，且违反最小权限原则
表单提交时的权限校验最容易被忽略
用户可能篡改表单字段名、值或隐藏域，所以表单提交目标接口（如 POST /api/orders）必须重新校验本次操作是否在用户权限范围内。
- 不要依赖
<input type="hidden" name="status" value="approved">来控制状态流转，后端必须检查当前用户是否有order:approve权限 - 敏感字段（如
is_admin、role）绝不能由前端传入，应由后端根据用户身份自动注入 - 即使表单里没出现“删除”按钮，也要防范用户手动构造
DELETE /api/orders/123请求，后端需校验该用户能否操作ID为123的资源 - 推荐在中间件层统一拦截：解析JWT获取
user_id和scopes，再比对请求路径与操作类型（如orders:delete）
最常被跳过的环节，是后端没对每个字段的读写做细粒度控制——比如返回了 customer_email 字段，却没考虑某些角色本不该看到它；或者允许用户修改自己的头像URL，却忘了校验该URL是否指向内部系统资源。数据权限不是“有没有”，而是“哪一行、哪一个字段、在什么条件下能被谁以什么方式访问”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
