Core Data类命名为Set与Swift原生Set冲突，无法改名如何处理？

方法1：直接显式调用Swift标准库的Set #

命名冲突本质是模块命名空间优先级问题，只需要在需要使用原生Set的位置加上Swift.前缀明确指定命名空间即可，完全不会影响功能：

// 原来的写法，现在会识别为你自定义的Core Data Set类
// let set = Set<Int>()

// 修改为如下写法即可调用原生Set
let nativeSet = Swift.Set<Int>()

如果嫌每次加前缀麻烦，可以在需要频繁使用原生Set的文件顶部自定义别名：

typealias SSet<T: Hashable> = Swift.Set<T>
// 后续直接使用SSet即可
let numSet = SSet<Int>([1,2,3])

方法2：解除Core Data类的命名冲突（完全不影响CloudKit） #

你不需要修改CloudKit对应的实体名称，只需要修改Core Data实体映射的Swift类名即可从根源解决冲突：

• 打开项目中的.xcdatamodeld文件，选中名为Set的实体
• 打开右侧工具栏的「数据模型检查器」（第三个标签页）
• 顶部Entity区域的Name字段保持不变（该字段对应CloudKit的记录类型，修改才会影响已部署的线上数据）
• 向下找到Class区域，把Name字段的取值从Set修改为其他不冲突的名称，例如CDSet、UserSet等，Module选择你的主项目模块，Codegen配置保持原有值即可
• 清理项目后重新编译，命名冲突直接消失，原有CloudKit同步逻辑不会有任何变更

关于NSSet的使用说明 #

可以使用但不推荐：

• NSSet属于Objective-C类型，和Swift原生Set支持无缝桥接，你可以随时在两种类型之间转换
• 缺点非常明显：NSSet是类型擦除的，在Swift中使用没有泛型约束，编译期无法检查元素类型，容易出现运行时错误，也无法享受Swift泛型的语法糖、高阶函数自动类型推导等特性

Swift/SwiftUI场景下的影响 #

如果使用Swift.Set方案 #

完全无影响，所有原生Swift、SwiftUI、Combine API需要原生Set类型的场景都可以正常使用，和无命名冲突时的使用效果100%一致，仅多了前缀或别名的差异。

如果使用NSSet方案 #

会存在如下问题：

• 大部分Swift原生API、SwiftUI容器/状态参数、Combine操作符都只接受Swift原生Collection类型，NSSet每次传入都需要先做桥接转换，代码冗余
• 无法直接做泛型遍历，所有元素都需要手动做类型转换，增加调试成本
• SwiftUI状态绑定场景下，类型不匹配可能会出现视图不刷新的隐性问题，排查难度高

内容的提问来源于stack exchange，提问作者Arturo Lee