真实权限必须由服务端控制，前端仅作安全降级和体验提示；权限表格需基于后端数据动态渲染，禁用CSS类或HTML属性做权限判断，所有敏感操作须经服务端鉴权。
HTML 本身不处理权限，别在 <div> 里写 role="admin"
HTML 是描述结构的标记语言，不是权限系统。你没法靠加个 class 或 data-permission 属性就让按钮对某人“不可见”或“禁用”——浏览器根本不认这些语义，后端也不自动读取它们。真实权限必须由服务端控制渲染逻辑，前端只做「安全降级」和「体验提示」。
常见错误现象：
– 页面上用 display: none 隐藏管理员菜单，但源码里仍存在 <a href="/admin/users">
– 给按钮加 disabled 却没校验接口是否真拒绝非授权请求
– 把 data-role="editor" 当成权限凭证传给 API
- 权限判断永远优先在服务端完成：模板渲染前查用户角色，只吐出该看的内容
- 前端可读取服务端注入的 JSON 权限上下文（如
<script>window.USER_PERMS = {can_edit: true}</script>），但不能反向依赖它做核心校验 - 所有敏感操作（提交、删除、导出）必须带服务端鉴权，前端禁用只是防误点，不是防线
怎么让协作成员看到自己有哪些权限？用服务端渲染的对照表格
权限预览本质是展示「当前用户被授予了哪些能力」，不是罗列全部系统权限。表格内容必须来自后端接口或模板变量，而非硬编码 HTML。
使用场景：成员进入项目设置页、点击「我的权限」弹窗、管理员分配角色后刷新预览
立即学习“前端免费学习笔记（深入）”；
- 表格列建议固定为：
功能模块、操作项、当前状态（✅ / ❌ / ⚠️） - 避免用文字描述权限（如“可编辑文档”），改用具体动作（
document:update、comment:delete），方便前后端对齐 - 如果权限粒度细（如按文件夹控制），表格需支持分组折叠，但首屏只展开用户最常接触的 3–5 项
- 注意兼容性：不要用
<details><summary>做权限分组，IE 和旧版 Safari 不支持；改用 JS 控制aria-expanded+display
示例（服务端已注入 window.CURRENT_USER_PERMISSIONS）：
<table aria-label="您的权限列表">
<thead><tr><th>模块</th><th>操作</th><th>状态</th></tr></thead>
<tbody>
<tr><td>文档</td><td>编辑</td><td><span aria-hidden="true">✅</span><span class="sr-only">已启用</span></td></tr>
<tr><td>评论</td><td>删除他人</td><td><span aria-hidden="true">❌</span><span class="sr-only">未启用</span></td></tr>
</tbody>
</table>
为什么不能用 CSS 类名当权限开关？.can-delete 是个危险信号
把权限映射到 CSS 类（比如给按钮加 class="btn can-delete" 再用 JS 判断是否存在）看似方便，实则埋下三类问题：
- 类名易被手动修改：开发者工具里删掉
can-delete就能触发隐藏按钮，而接口可能没做鉴权 - 维护成本高：新增一个权限就得同步改 HTML、CSS、JS 三处，且无法做自动化权限审计
- 性能隐患：频繁查询
element.classList.contains()在复杂页面中拖慢交互响应
正确做法是统一从单一可信源读取权限状态，例如：
- 服务端模板中直接输出布尔值：
<button type="button" data-action="delete" <%= can_delete ? '' : 'disabled' %>>删除</button> - 前端 JS 中只读
window.USER_PERMS.document_delete === true，不查 DOM - 权限变更时（如管理员刚授予权限），走完整 reload 或 fetch 新权限数据再重绘 UI，不 patch 类名
权限表格里的「⚠️」符号代表什么？别让它变成模糊地带
「⚠️」常用于表示「有条件可用」，比如「仅对自己创建的文档可编辑」。但它极易引发歧义——用户不知道条件是什么，前端也不知道该不该禁用按钮。
容易踩的坑：
– 表格里写「⚠️ 编辑」，但按钮始终启用，点进去才发现报错「无权编辑此文档」
– 把「⚠️」当成占位符，没配套提供 hover 提示或跳转说明链接
- 每个 ⚠️ 必须绑定明确的判定逻辑，并在表格对应行提供简短说明（如「仅限本人创建」）
- 前端按钮应根据实时上下文判断：打开文档时查
doc.owner_id === current_user.id，再决定是否启用，而不是依赖表格里的静态 ⚠️ - 服务端返回的权限数据里，避免用字符串字段存条件逻辑（如
"condition": "owner_only"），改用结构化字段："can_edit": {"reason": "owner_only", "applies_to": ["self_created"]}
权限不是装饰性信息，表格里每一条 ✅/❌/⚠️ 都得能在代码里找到对应分支判断。否则预览就只是幻觉。
