Set.prototype.union() 尚未标准化，生产环境不可用；最小特权权限合并应取各来源交集而非并集，以确保权限范围最窄、安全性最高。
Set.prototype.union() 本身并不存在于当前 JavaScript 标准（截至 ECMAScript 2024），它是一个**尚未被正式采纳的提案（Stage 3）**，目前仅在部分浏览器（如 Chrome 120+）中作为实验性功能启用，且需手动开启 flag 或依赖 polyfill。因此，直接使用 Set.prototype.union() 实现权限合并并不具备生产可用性。
实际可行的“最小特权”多源权限去重方案
所谓“最小特权”，是指合并多个权限集合时，**不放大权限（不取并集），而是取交集**——即用户仅保留所有来源都认可的权限，这是真正的最小化、最安全的合并逻辑。而“自动去重”是 Set 天然特性，关键在于选对集合运算。
推荐用原生 Set 配合 Array.reduce() 和交集逻辑实现：
- 将每个权限源转为
Set（自动去重） - 以第一个源为基准，逐个与其他源求交集（
filter + has） - 最终结果即为所有源共有的权限 —— 满足最小特权原则
代码示例：安全的多源权限交集合并
假设你有三个权限来源（API、角色配置、用户直授）：
const permissionsFromApi = ['read:users', 'write:posts', 'delete:comments'];
const permissionsFromRole = ['read:users', 'read:posts', 'write:posts'];
const permissionsFromUser = ['read:users', 'write:posts', 'manage:settings'];
// 转为 Set 并求交集
const allSources = [permissionsFromApi, permissionsFromRole, permissionsFromUser]
.map(src => new Set(src));
const minPrivilegeSet = allSources.reduce((acc, curr) => {
return new Set([...acc].filter(p => curr.has(p))));
});
console.log([...minPrivilegeSet]);
// → ['read:users', 'write:posts']（仅两者都存在的权限）
为什么不是并集？警惕“最小特权”的常见误解
“最小特权”常被误认为“最少权限项数”，实则指**权限范围最小、能力边界最窄**。例如：
- 并集：
['read:users', 'write:posts', 'delete:comments', 'read:posts', 'manage:settings']→ 权限面过宽，违反最小化原则 - 交集：
['read:users', 'write:posts']→ 所有系统一致授权，无额外能力，真正最小可信集
在 RBAC 或 ABAC 场景中，交集合并天然适配“多审批流”“多租户策略叠加”等需严格收敛权限的业务。
如需未来兼容 union() 提案，可封装过渡层
若团队希望提前适配提案语法，可自行封装带降级的 union 和 intersection 方法：
const setUtils = {
union(...sets) {
if (typeof Set.prototype.union === 'function') {
return sets.reduce((a, b) => a.union(b));
}
return new Set(sets.flatMap(s => [...s]));
},
intersection(...sets) {
if (sets.length === 0) return new Set();
return sets.reduce((acc, curr) =>
new Set([...acc].filter(x => curr.has(x))))
}
};
// 使用
const finalPerms = setUtils.intersection(
new Set(permissionsFromApi),
new Set(permissionsFromRole),
new Set(permissionsFromUser)
);
不复杂但容易忽略：权限合并的本质是策略决策，不是技术炫技。用对交集，比等待一个未落地的 union() 方法更重要。
