知识文章 · 编写日期 2026-11-10
搜同社群：一个角色关权限就算撤回吗
不一定。以Discord的普通成员为例，服务器基础权限会合并@everyone与该成员所有角色的允许项。只在角色A里关掉一项，而角色B仍授予同一项，成员的基础结果仍包含它。应查清允许来自哪里，再讨论是否已完成撤回。
搜同同伴交流专题中的社群设置阅读知识。本页只以Discord官方2026年11月10日可查文档说明机制，不认定搜同使用Discord，也不提供群组入口。图为虚构配置；成员不是服务器所有者、没有Administrator，未实际登录或修改任何服务器。
先把服务器基础权限与频道覆盖分开
Discord官方帮助说明，成员的服务器权限由@everyone与已分配角色的允许项共同决定。[1] 开发者文档的基础计算把各角色权限做按位或运算；其中服务器所有者和Administrator另有特殊处理。[2] 本题排除这两个例外，只看一项普通权限P。
P选“修改自己的服务器昵称”（CHANGE_NICKNAME），而不是替别人改名。它便于说明：同一个人可能持有多个角色，某角色不提供P，并不会否决另一角色给出的P。这里的0表示未授予，不是频道覆盖配置中的显式拒绝。
原创算例：关闭A以后，B还在提供什么
题设只有@everyone、角色A、角色B三个来源。@everyone没有P；管理者刚在A中关掉P；B仍开启P，且这个成员仍持有B。按这一项来写，结果为0或0或1＝1。图中的1只是单个布尔标记，不是Discord完整权限整数。
若下一步从该成员身上移除B，在本题全部条件不变且没有其他角色的前提下，参与合并的只剩0和0，该项结果才变为0。这是题设推导，不是建议直接删掉一个实际角色；移除角色还可能连带影响它提供的其他能力。
调整角色高低，不能代替找允许来源
同一基础权限的或运算不依赖A、B谁排在上面。把未开启P的A拖到B上方，不会把0或1变成0。角色层级确实影响哪些角色或成员可被管理，但那是另一套限制，不能拿显示位置覆盖这里的合并规则。[2]
核对时可列“角色名称、该成员是否持有、是否授予P”三栏。即使角色叫“只读”或“访客”，也应读具体配置；名称只是管理者起的标签，不自动成为技术限制。先查看完整角色列表，才能找出遗漏的允许来源。
这个结果不能直接搬到频道私密性判断
频道还存在针对@everyone、角色和成员的覆盖配置；官方文档将它列为基础结果之后的另一段处理。[1][2] 本图没有给这些字段，也没有计算查看频道或发送消息，所以不能据图宣布某个频道已经私密。
如果需要复查真实配置，应由有权限的管理者以无敏感内容的测试场景核对对应成员、具体动作和适用范围。记录预期与观察结果即可，不用收集同伴真实身份、私人聊天或照片来证明权限是否生效。
动手核对
- 明确要核对的具体能力，区分改自己昵称与管理他人昵称。
- 列出@everyone及该成员全部角色，找出每一处允许来源。
- 先算普通成员基础结果，再按实际问题另查频道覆盖或管理层级。
- 涉及实际变更时先核对连带影响，并用无敏感测试材料确认结果。
常见问题
A关掉P就是给成员投了一张禁止票吗？
在本页服务器基础权限合并里不是。它只表示A不授予P，其他已分配角色的允许仍会计入。
把A放到最高就能压过B吗？
不能改变本题的基础或运算。管理角色和成员时的层级限制，应与此分开核对。
拿到修改自己昵称的能力，就能修改别人的昵称吗？
不能。官方文档把CHANGE_NICKNAME与MANAGE_NICKNAMES列为不同权限，不能把对象范围扩大。
依据与延伸阅读
- [1] How is the permission hierarchy structured?（Discord Support，核验日期 2026-11-10）
服务器允许项合并与频道覆盖另行处理；此处使用当前可查官方说明。
- [2] Permissions：基础计算与权限表（Discord官方开发者文档，核验日期 2026-11-10）
compute_base_permissions逐角色按位或、owner/Administrator例外、CHANGE_NICKNAME及MANAGE_NICKNAMES区分、角色层级适用范围。