历史
在 Swift 4 之前，String 类型遵循 Collection，切片操作返回新的 String 实例。这个设计需要在创建子字符串时复制底层字符数据，导致每个切片操作的时间复杂度为 O(n)。在性能关键的文本处理过程中，例如解析大文档或日志文件，重复切片会累积到平方复杂度和过高的内存压力，从而严重降低吞吐量。
问题
根本问题在于 String 是一种值类型，独占其存储。当一个切片返回一个新的 String 时，必须复制存储以确保值语义的独立性。这种急切的复制对逐步切片字符串的算法（例如标记解析器或解析器）是灾难性的，因为每个中间切片都会复制内存，即使数据被立即丢弃或仅被暂时检查。
解决方案
Swift 4 引入了 Substring，作为一种代表 String 底层存储部分视图的独特值类型。Substring 共享与原始 String 相同的缓冲区，使用索引范围来限制可见部分，而无需复制字符数据。这样实现了 O(1) 的切片复杂度，例如 let slice = largeString[range] 返回 Substring 视图而不是副本。类型系统通过要求将 Substring 明确转换为 String 来防止这些视图意外被长期保留，通常通过 String(slice) 或插值，此时执行实际的复制。这种在语义边界上的 "写时复制" 行为确保了高效的管道，同时保持内存安全。
想象一下开发一个高吞吐量的日志分析器，用于处理逐行分析多千兆字节的文本文件。每行包含结构化数据，包括时间戳、日志级别和可变长度消息。初始实现使用 String 切片来提取这些字段，假设值语义将提供安全性而不会产生重大成本。
解决方案 1：幼稚的字符串切片
第一个方法利用标准的 String 下标提取组件，为每个标记创建新的 String 实例。虽然这提供了干净、不可变的数据以供处理，但分析表明，有 80% 的执行时间花费在 malloc 和 memmove 操作上，这些操作复制了字符数据。由于中间字符串在释放之前累积，内存使用随着文件大小线性增长，导致应用程序在处理大输入时耗尽可用 RAM。
解决方案 2：使用不安全指针的手动索引管理
第二种方法考虑使用 UnsafeMutablePointer<UInt8> 直接访问原始的 UTF-8 字节，手动跟踪开始和结束索引以避免复制。这消除了分配开销，实现了所需的性能，但引入了显著的复杂性和安全风险。代码需要手动边界检查，并且失去了 Swift 的 Unicode 正确的字形集群保证，在处理多字节字符或表情符号时可能导致崩溃或解析错误。
解决方案 3：采用 Substring
选择的解决方案重构了解析器以在所有中间标记步骤中使用 Substring。通过从分割操作中返回 Substring 视图，解析器以 O(1) 的切片操作处理文件，保持近乎恒定的内存开销，而不管文件大小。关键的长期存储（例如将错误消息插入到数据库缓存中）仅在必要时显式转换相关的 Substring 实例为 String，从而减少对大型底层缓冲区的引用。这样平衡了 Swift 字符串模型的安全性与系统级文本处理的性能要求。
结果
重构使内存消耗减少了 95%，解析吞吐量提升了 400%。该应用程序现在可以在适度的硬件上处理 TB 级别的日志档案，而不会触发内存压力警告或垃圾回收暂停，验证了这一架构选择。该解决方案保持了完整的 Unicode 合规性和类型安全，避免了不安全指针操作的陷阱，同时提供了 C 级的性能特征。
转换 Substring 到 String 是否总是执行复制，或者是否有优化允许共享存储持续存在？
通过 String(substring) 初始化程序将 Substring 转换为 String 时，总是会将相关字符数据复制到新的独立拥有的存储中。Swift 不提供 String 的“子字符串共享”模式，因为这将违反值语义——对原始字符串的任何修改将可见地影响“复制”字符串，破坏值类型的基本契约。复制操作的复杂度为 O(n)，基于子字符串的长度，因此推迟转换直到必要并避免长期存储子字符串是至关重要的。
为什么 Swift 编译器阻止在函数参数中隐式转换 Substring 到 String，以及这如何防止内存泄漏？
Swift 要求显式转换，因为 Substring 保持对整个原始 String 存储缓冲区的引用，而不仅仅是可见切片。如果允许隐式转换，将从 1GB 文件中提取的小 10 字符 Substring 传递到长寿命缓存中，将无声无息地保留整个千兆字节的内存。通过强制开发者编写 String(slice)，该语言使得昂贵的复制操作变得显式且可见，提醒人们长期存储成本与轻量级视图之间的显著差异。
Substring 如何在将数据传递到 Foundation API（如 NSString 方法）时与 Objective-C 桥接？
在桥接到 Objective-C 时，Substring 必须转换为 NSString，这需要将相关的 UTF-8 或 UTF-16 数据复制到新的 NSString 实例，因为 NSString 需要连续的、不可变的存储。与 String 不同，如果 String 已经是本地的，可能通过免桥接直接桥接到 NSString而无需复制，Substring 在跨越到 Foundation 类时始终会产生复制开销。这种不对称性让开发者产生意外，当他们期望零成本桥接时；高效的互操作需要首先显式转换为 String（这也会复制），或使用接受范围的 NSString API。