将GrantedAuthority视为“权限”或“权利”。这些“权限”（通常）用字符串表示（使用
getAuthority()方法）。这些字符串使您可以识别权限，并让您的选民决定他们是否授予访问权限。
您可以通过将用户置于安全上下文中来为其授予不同的GrantedAuthority（权限）。通常，您可以通过实现自己的UserDetailsService来实现此目的，该服务返回一个UserDetails实现，该实现返回所需的GrantedAuthorities。
角色（在许多示例中使用过）只是“权限”，使用命名约定表示角色是以prefix开头的GrantedAuthority
ROLE_。没什么了
一个角色就是一个GrantedAuthority-一个“权限”-一个“权利”。您会在Spring
Security中看到很多地方，带有
ROLE_前缀的角色是专门处理的，例如在RoleVoter中，
ROLE_前缀被用作默认值。这样，您就可以提供角色名称而无需添加
ROLE_前缀。在Spring安全4之前，没有非常一致地遵循对“角色”的这种特殊处理，并且权限和角色通常被视为相同（例如，
hasAuthority()
hasRole()）。使用Spring
Security
4，角色的处理更加一致，处理“角色”的代码（如
RoleVoter，
hasRole表达式等）总是
ROLE_为您添加前缀。所以
hasAuthority('ROLE_ADMIN')指一样hasRole('ADMIN')，因为ROLE_前缀被自动添加。有关更多信息，请参见Spring
Security 3到4 迁移指南。
但是，角色仍然只是带有特殊
ROLE_前缀的授权机构。因此在Spring安全性3
@PreAuthorize("hasRole('ROLE_XYZ')")中与相同@PreAuthorize("hasAuthority('ROLE_XYZ')")，在Spring安全性4@PreAuthorize("hasRole('XYZ')")中与相同@PreAuthorize("hasAuthority('ROLE_XYZ')")。关于您的用例：
用户具有角色，角色可以执行某些操作。
您可能最终会
GrantedAuthorities遇到用户所属的角色以及角色可以执行的操作。在
GrantedAuthorities对角色有前缀
ROLE_和操作都有前缀
OP_。一个例子为业务主管部门可能是
OP_DELETE_ACCOUNT，
OP_CREATE_USER，
OP_RUN_BATCH_JOB等角色可以是
ROLE_ADMIN，
ROLE_USER，
ROLE_OWNER等。
您最终可能会
GrantedAuthority像下面的（伪代码）示例中那样使您的实体实现：
@Entityclass Role implements GrantedAuthority { @Id private String id; @ManyToMany private final List<Operation> allowedOperations = new ArrayList<>(); @Override public String getAuthority() { return id; } public Collection<GrantedAuthority> getAllowedOperations() { return allowedOperations; }}@Entityclass User { @Id private String id; @ManyToMany private final List<Role> roles = new ArrayList<>(); public Collection<Role> getRoles() { return roles; }}@Entityclass Operation implements GrantedAuthority { @Id private String id; @Override public String getAuthority() { return id; }}您在数据库中创建的角色和操作的ID将是GrantedAuthority表示形式，例如
ROLE_ADMIN，
OP_DELETE_ACCOUNT等等。对用户进行身份验证时，请确保从UserDetails.getAuthorities（）返回了其所有角色的所有GrantedAuthority和相应的操作方法。
例如：ID为admin角色
ROLE_ADMIN有操作
OP_DELETE_ACCOUNT，
OP_READ_ACCOUNT，
OP_RUN_BATCH_JOB分配给它。ID为的用户角色具有
ROLE_USER操作
OP_READ_ACCOUNT。
如果造成安全上下文管理员日志将有GrantedAuthorities： ，
ROLE_ADMIN，，
OP_DELETE_ACCOUNT``OP_READ_ACCOUNT``OP_RUN_BATCH_JOB
如果一个用户登录它，它就会有：
ROLE_USER，
OP_READ_ACCOUNT
UserDetailsService将注意收集所有角色以及这些角色的所有操作，并通过返回的UserDetails实例中的getAuthorities（）方法使它们可用。
