Swift开发之String 还是 NSString

关键时刻，第一时间送达！

既然像 这样的 Swift 的类型和 Foundation 的对应的类是可以无缝转换的，那么我们在使用和选择的时候，有没有什么需要特别注意的呢？

简单来说，没有特别需要注意的，但是尽可能的话还是使用原生的 类型。

原因有三。

首先虽然 和 有着良好的互相转换的特性，但是现在 Cocoa 所有的 API 都接受和返回 类型。我们没有必要也不必给自己凭空添加麻烦去把框架中返回的字符串做一遍转换，既然 Cocoa 鼓励使用 ，并且为我们提供了足够的操作 的方法，那为什么不直接使用呢？

其次，因为在 Swift 中 是 struct，相比起 的 类来说，更切合字符串的 "不变" 这一特性。通过配合常量赋值 (let) ，这种不变性在多线程编程时就非常重要了，它从原理上将程序员从内存访问和操作顺序的担忧中解放出来。另外，在不触及 特有操作和动态特性的时候，使用 的方法，在性能上也会有所提升。

最后，因为 实现了像 这样的接口，因此有些 Swift 的语法特性只有 才能使用，而 是没有的。一个典型就是 的枚举，我们可以写：

而如果转换为 的话，是无法编译的。

不过也有例外的情况。有一些 的方法在 中并没有实现，一个很有用的就是在 iOS 8 中新加的 。我们想使用这个 API 来简单地确定某个字符串包括一个子字符串时，只能先将其转为 ：

A> Swift 的 没有 是一件很奇怪的事情，理论上应该不存在实现的难度，希望只是 Apple 一时忘了这个新加的 API 吧。当然你也可以自行用扩展的方式在自己的代码库为 添加这个方法。当然，还有一些其他的像 和 这样的 API 也没有 的版本，这主要是因为 和 在处理编码上的差异导致的。

使用 唯一一个比较麻烦的地方在于它和 的配合。在 中，我们在匹配字符串的时候通常使用 来表征结果或者作为输入。而在使用 的对应的 API 时， 也会被映射成它在 Swift 中且对应 的特殊版本：。这有时候会让人非常讨厌：

一般来说，我们可能更愿意和基于 的 一起工作，而不喜欢使用麻烦的 。这种情况下，将 转为 也许是个不错的选择：

来自：王巍 (@onevcat)

程序员大咖整理发布，转载请联系作者获得授权