这个设计决定源于Swift对标准库集合的值语义的基本承诺。与Objective-C的NSMutableDictionary或C++的std::unordered_map不同，后者暴露引用语义或允许外部指针指向内部节点，Swift将Dictionary和Set视为纯值类型。当Swift为这些集合采用Copy-on-Write（COW）优化，以达到引用类型性能的同时保持值类型的安全性时，工程团队面临一个关于索引稳定性的关键决定。决议是在变更时使索引失效，以防止在哈希表增长、碰撞解决或条目删除时出现悬挂引用到重新分配的存储。
核心问题源于COW语义与哈希表实现细节之间的互动。当Dictionary通过插入或删除进行变更时，如果负载因子超过阈值，可能会触发重新调整大小，分配新的、更大的缓冲区并重新哈希所有条目。任何在变更之前创建的现有Index值封装了对旧缓冲区物理内存的偏移量或指针。如果在变更后访问该索引，将取消引用已释放的内存（use-after-free）或返回来自错误桶的数据。由于Swift无法跟踪在独立的Dictionary副本中的每个Index值的生命周期（值语义允许无限制复制），因此它无法安全地更新所有未解决的索引。因此，语言必须声明这些索引无效，以维持内存安全保证。
Swift通过在Dictionary的内部存储头中嵌入一个世代计数或版本号来解决这个问题。每个Index在创建时捕获这个世代标识符。当Dictionary发生变更时，运行时会递增这个世代计数，并可能重新分配基础缓冲区。任何后续使用过时的Index都会将其存储的世代与当前世代进行比较；不匹配将触发确定性的运行时错误（预条件失败）。这种方法牺牲了变更过程中的索引稳定性，以换取内存安全和值语义的完整性。对于COW优化，运行时在变更前检查引用计数：如果唯一引用，则进行就地变更（使索引失效）；如果是共享的，首先复制缓冲区，使原实例的索引有效，而新副本获得一个新的世代计数。
var marketData: [String: Double] = ["AAPL": 150.0, "GOOGL": 2800.0] let indexBeforeUpdate = marketData.index(forKey: "AAPL")! // 世代 0 marketData["TSLA"] = 700.0 // 变更递增世代，可能重新分配 // 运行时错误：尝试使用世代 0 的无效索引进行访问 // let price = marketData[indexBeforeUpdate]
一个开发团队正在使用Swift在iPad上构建一个高频交易仪表板，利用Dictionary来缓存带有String股票代码的实时价格数据。为了在快速更新期间优化UI呈现性能，他们在视图模型中存储直接的Dictionary索引，以避免在表视图单元格配置期间重复的哈希计算。然而，当后台WebSocket线程向字典插入新的价格点时，应用程序出现了间歇性的崩溃，显示EXC_BAD_ACCESS或从已释放的内存区域显示损坏的数据，因为缓存的索引用于引用在调整大小操作中重新分配的哈希表桶。
考虑的第一个解决方案是迁移到NSMutableDictionary，它来自Foundation，提供引用语义和稳定的对象引用而不是值语义。这种方法将允许团队在字典变更后保持对条目的持久引用，从而在应用程序生命周期中保持类似索引的稳定性。然而，这引入了引用语义，打破了视图模型之间的值类型隔离，导致在后台队列和主线程之间复制字典时产生意外的数据共享和竞争条件。此外，NSMutableDictionary缺乏Swift的泛型类型安全，并且对于像struct实例这样的值类型需要昂贵的桥接开销，导致了性能下降。
探索的第二个解决方案是使用UnsafeMutablePointer实现自定义开放寻址哈希表，以手动管理稳定的节点内存地址，从而完全绕过Swift的索引失效机制。这将为存储的索引提供确定性的指针稳定性，允许O(1)访问，而不会在查找期间产生重新哈希的开销。然而，这种方法需要手动内存管理与malloc和free，如果节点在删除时未正确释放，将引入显著的内存泄漏风险。它也绕过了Swift的COW优化，意味着每个字典的副本都需要对堆分配的缓冲区进行完整的深复制，从而使超过一万条目的数据集的性能受到破坏。
团队最终选择了第三个解决方案：完全消除索引缓存，而是将键的数组（String股票代码）存储在他们的视图模型中，在每个单元格配置周期中根据键进行查找。这种方法的选择是因为它维护了Swift的值语义和内存安全保证，同时仍提供O(1)的平均查找性能。尽管在每次访问时计算密钥的哈希会带来成本，但现代Swift的字符串哈希通过SipHash高度优化，并且安全保证超越了微秒级的性能损失。他们还采用了来自开源Swift Collections包的OrderedDictionary类型，以在不依赖于不稳定索引的情况下提供确定性排序。
结果是在随后的三个月监控期间，完全消除了EXC_BAD_ACCESS崩溃。即使有50,000个并发价格条目，应用程序的内存占用仍然保持稳定，并且代码库在没有UnsafeMutablePointer操作的复杂性时变得更加可维护。团队建立了一项严格的架构指南，禁止在任何变更边界跨越存储Dictionary或Set索引，并在他们的内部维基中记录了这一模式，以防止未来的回归。
为什么Swift的Array在某些变更后允许索引重用，而Dictionary则不允许，尽管两者都是具有COW语义的值类型？
Array索引是轻量级的Int值，表示从连续存储的基地址的偏移量。虽然触发重新分配的Array变更（例如超过容量进行追加）在技术上通过移动缓冲区使索引失效，但Array索引不携带用于验证的世代元数据，使得它们缓存起来是危险的，但不会被显式检查。然而，Dictionary索引封装了复杂的内部状态，包括稀疏哈希表中的桶偏移。由于哈希表条目在重新哈希期间（由负载因子阈值或碰撞解决触发）不可预测地移动，整数偏移失去了语义意义。Swift理论上可以为Dictionary实现逻辑索引间接，但这将需要额外的指针追踪，从而减慢每次访问。因此，Dictionary和Set通过世代计数积极验证和使索引失效，而Array索引则依赖程序员确保有效性，反映了连续存储与哈希存储之间的不同性能和安全权衡。
Copy-on-Write机制如何判断当前实例的Dictionary变更是否需要使索引失效，还是创建一个带有新索引的新副本？
Swift在内部缓冲区（_NativeDictionary）上使用引用计数。在任何变更之前，运行时会调用isUniquelyReferencedNonObjC来检查缓冲区的引用计数。如果计数为1（唯一拥有），则就地进行变更，只使该特定实例上的索引失效，并通过递增世代计数。如果引用计数超过1（共享拥有），Swift将分配一个新缓冲区，复制所有元素，并在新副本上执行变更。原始实例保持不变并具有有效的索引，而新副本以新的世代计数开始（有效上为索引零）。这个区别对于值语义至关重要：在值赋值之后，两个变量共享存储，直到一个发生变更，从而触发惰性复制。变更点就是逻辑分割的地方，确保变更实例在修改之前具有唯一的拥有权。
是否可以使用withUnsafeMutablePointer或Unmanaged绕过Swift的Dictionary索引失效以访问原始存储，这会引入什么灾难性风险？
从技术上讲，UnsafeMutablePointer和Unmanaged可以通过withUnsafeMutablePointer直接访问Dictionary的底层存储，或通过将Dictionary强制转换为原始字节进行访问。然而，这构成了未定义的行为。Dictionary的内部布局是不透明的，可能在Swift版本之间发生变化（韧性）。直接指针操作绕过世代计数检查，允许在调整大小期间发生重新分配时访问已释放的内存。此外，哈希表维护复杂的关于占用位图和已删除条目的墓碑标记的不变量。手动指针操作可能会破坏这些不变量，导致探测序列中的无限循环、静默数据损坏或后续Dictionary操作中的崩溃。Swift的安全模型明确禁止这种情况；维护稳定引用的唯一安全机制是使用键（每次访问时重新哈希）或将值从集合中复制到单独的数组中。