一、它是什么：一个容器

Roles 元素的作用很单纯：包含父元素下定义的角色（Role）集合。它本身不含业务逻辑，只做归类。

二、两层含义，规则截然不同

挂在服务器下：集合里只有一个角色，名为 Administrators，代表服务器管理员角色。这个角色不能修改、不能删除，也不能往集合里添加新的角色。

挂在数据库下：集合里是该数据库定义的角色，可以按业务需要增删改——这才是日常做权限设计的地方。

所以"服务器级不能加角色"不是 bug，也不是权限不足，而是设计如此：它能做的只有一件事——标记谁是服务器管理员。

三、这个设计背后的逻辑

原因不难理解：服务器级权限影响面最大，一旦允许自定义角色，很容易出现"某个角色实际上等价于管理员"这种隐形越权。把这一层收敛成单一角色，等于强制你把细分权限放到数据库层去做。

四、常见的三个误区

1. 在服务器层找"新建角色"按钮：找不到是正常的，去数据库层操作；
2. 试图删除 Administrators：它不可删除也不可修改，把它当成系统内置项；
3. 以为数据库角色能跨库生效：角色归属某个数据库，换个库就要重新配。

五、正确的权限设计姿势

• 服务器级只留少数人：管理员角色成员越少越好，且要有审计；
• 业务权限全部下沉到数据库层：按"看什么、改什么"划分角色，而不是按部门名字堆角色；
• 角色命名写清用途：如"销售报表只读"，比"Role1"能让半年后的自己少猜十分钟；
• 定期复核成员：角色本身不会出错，成员会随时间失控。

一句话总结：这个元素教你一件事——权限体系是分层的，越往上越收敛。想在服务器层做精细授权，方向就错了；把角色放在数据库层，才是它被设计出来的用法。