HTML协作成员权限预览表详解

• 权限判断永远优先在服务端完成：模板渲染前查用户角色，只吐出该看的内容
• 前端可读取服务端注入的 JSON 权限上下文（如 ），但不能反向依赖它做核心校验
• 所有敏感操作（提交、删除、导出）必须带服务端鉴权，前端禁用只是防误点，不是防线

怎么让协作成员看到自己有哪些权限？用服务端渲染的对照表格

权限预览本质是展示「当前用户被授予了哪些能力」，不是罗列全部系统权限。表格内容必须来自后端接口或模板变量，而非硬编码 HTML。

使用场景：成员进入项目设置页、点击「我的权限」弹窗、管理员分配角色后刷新预览

• 表格列建议固定为：功能模块、操作项、当前状态（✅ / ❌ / ⚠️）
• 避免用文字描述权限（如“可编辑文档”），改用具体动作（document:update、comment:delete），方便前后端对齐
• 如果权限粒度细（如按文件夹控制），表格需支持分组折叠，但首屏只展开用户最常接触的 3–5 项
• 注意兼容性：不要用
  做权限分组，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() 在复杂页面中拖慢交互响应

正确做法是统一从单一可信源读取权限状态，例如：

• 服务端模板中直接输出布尔值：>删除
• 前端 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"]}

权限不是装饰性信息，表格里每一条 ✅/❌/⚠️ 都得能在代码里找到对应分支判断。否则预览就只是幻觉。

今天关于《HTML协作成员权限预览表详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！