阿里，这是个有趣的场景.
这里有两个问题您需要回答。

第一个问题-公开数据时，系统只会进行筛选，还是您会执行其他操作？例如，如果您公开类似 users/{id} 的操作，则需要检查授权，并确保用户有权访问该操作。如果您只是公开类似 /users 的操作，则只需进行筛选即可。因为您将只公开当前用户有权查看的用户，这种区别将决定很多实现。
第二个问题是-您可以接受多少手动工作？

一方面，您可以根据框架的需要调整数据，并尽可能依赖于内置功能（安全表达式、ACL）;另一方面，您可以根据数据的结构调整代码，并更多地手动执行操作。
这是我首先关注的两个因素，因为基于这四个决定，实施将看起来完全不同。
最后，要回答您的“ACL是否可以扩展”问题，请注意两点。第一，您需要进行测试。是的，ACL可以扩展，但如果不进行测试，它是否可以扩展到10 K或100 K，这是一个无法具体回答的问题。
第二，当你进行测试时，考虑现实的场景。理解你的解决方案的局限性当然很重要。但是，除此之外，如果你认为你的系统会有100万个实体--很好。但是如果它不会--那么就不要把它作为一个目标。
希望能有所帮助。

使用Spring，您可以使用以下内容：
1)您可以使用SpEL EvaluationContext扩展，使安全属性和表达式在@Query注解的SpEL表达式中可用。这允许您仅获取与当前用户相关的业务对象：

interface SecureBusinessObjectRepository extends Repository<BusinessObject, Long> {
    @Query("select o from BusinessObject o where o.owner.emailAddress like ?#{hasRole('ROLE_ADMIN') ? '%' : principal.emailAddress}")
    List<BusinessObject> findBusinessObjectsForCurrentUser();
}

2)您可以参照Bean并在Web安全表示式中使用路径变数。这可让您只授与目前使用者可以存取的对象：

@Service
public class UserService {
    public boolean checkAccess(Authentication authentication, int id) {
        // ...
    }
}
@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    // ...
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
            .antMatchers("/businessObjects/{id}/**").access("@userService.checkAccess(authentication, #id)")
            // ...
    }
}

检查my demo project以了解更多详细信息。在本例中，如果用户属于与这些用户相关的类别，则用户可以访问工作室。管理员可以访问所有工作室。