Swift中同时遵循Hashable与Identifiable协议的作用是什么？

先明确两个协议的核心定位：

• Identifiable 是SwiftUI官方推荐的、给视图提供稳定唯一标识的协议，通过要求类型实现id属性，让ForEach、List等组件能精准追踪视图的添加、删除、更新，避免不必要的重渲染。
• Hashable 是Swift标准库的协议，核心作用是支持类型的哈希计算与相等性判断，除了能在无id时临时作为Identifiable的替代（用\.self作为标识），还有更多通用场景需求。

回到你的代码，明明已经通过UUID实现了Identifiable的id，还要同时遵循Hashable，主要有这几个原因：

1. 满足其他API的场景需求 #

很多Swift生态的API依赖Hashable：

• 把Friend实例存入Set<Friend>，或者作为Dictionary<Friend, SomeValue>的键，必须要求Friend是Hashable；
• SwiftUI中的一些交互逻辑，比如List的多选绑定（@Binding var selectedFriends: Set<Friend>）、Picker选择单个实例（@State var selectedFriend: Friend?），都需要类型遵循Hashable才能正常工作；
• 自定义动画或状态判断时，需要比较实例的相等性，Hashable继承自Equatable，能直接用==判断两个实例是否相等。

2. 兼顾稳定性与灵活性 #

用Identifiable的id作为标识是最稳定的（比如UUID不会随实例属性变化而改变），能保证SwiftUI视图状态的一致性；而Hashable则提供了基于实例本身的哈希与相等判断能力，如果后续有需要直接比较实例内容的场景（比如判断两个Friend的所有属性是否完全一致），不用额外实现Equatable。

3. 提前适配未来扩展 #

在项目迭代过程中，你可能会突然需要把Friend用在需要Hashable的场景里（比如新增一个收藏功能，用Set存储用户收藏的好友）。提前遵循协议可以避免后续修改结构体定义、重新适配相关代码的麻烦，尤其在大型项目或团队协作中，这种提前兼容能减少重构成本。

另外补充个小提醒：用Hashable的\.self作为Identifiable的替代是临时方案，当实例属性变化时，哈希值会改变，可能导致SwiftUI视图异常重渲染或状态丢失。所以官方始终推荐优先实现Identifiable的稳定id，而Hashable是作为额外能力补充，不是替代。

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