答案。

Swift 中的 extensions 是一种扩展类型的手段——可以是标准类型（例如 String、Array）或自定义类型，而无需创建继承类或修改原始源代码。这使我们能够添加新的方法、计算属性、协议遵从性，甚至对协议的符合性，同时保持代码的可读性和统一架构。

问题发生在过度或无序使用 extensions 时：很容易失去对类型原始行为的控制，可能会出现命名冲突，并且在大型项目或引入第三方库时更难追踪代码的来源。

解决方案 是清晰结构化，按逻辑组组织 extensions，明确文件文档，并避免与现有名称冲突，如果需要，限制作用域（例如通过 fileprivate 或 internal）。

代码示例：

extension String {
    var isEmail: Bool {
        return self.contains("@") && self.contains(".")
    }
    func trimmed() -> String {
        return trimmingCharacters(in: .whitespacesAndNewlines)
    }
}

关键特点：

允许添加新的方法、属性和协议遵从性，无需访问源代码。
不支持存储新属性 — 仅支持计算属性和函数。
可以通过 fileprivate/internal 限制可见性。

陷阱问题。

可以通过 extension 添加存储属性吗？

不可以，extension 只能添加计算属性和方法。存储属性无法通过 extension 添加。尝试一下，编译器将立即报错。

如果在不同文件中的两个不同 extension 中声明了同名方法会发生什么？

将出现命名冲突，并且 Swift 无法决定调用哪个方法，错误将出现在编译阶段。

extensions 能否实现仅在 extension 内部可见的私有方法？

可以，如果通过 private 声明方法，它将仅在该 extension 和声明它的文件内部可见（如果使用 fileprivate）。

extension Int {
    private func isEvenInternal() -> Bool {
        return self % 2 == 0
    }
    func publicCheckEven() -> Bool {
        return isEvenInternal()
    }
}

常见错误和反模式

反模式：在一个 extension 中添加大量不同类型的函数而没有逻辑分组。
错误：不遵守作用域规则（例如，使用 public 为使用 internal 细节的函数创建 extension）。
在与库合作或不同开发者为同一类型编写 extension 时，未达成任务范围一致而导致命名冲突。

实际案例

负面案例

在一个大型项目中，通过 extension 向 String 添加了各种方法——从邮箱验证到 JSON 解析。一年后，没人能搞清楚来源何处：方法名重叠，有人添加了新函数，却不知道旧函数的存在，从而破坏了依赖的行为。

优点：

快速添加新功能，不触动原始类型。

缺点：

混乱、重复、错误、不可预测的行为、维护困难。

积极案例

团队通过 extensions 使用逻辑分组：一个 extension 用于验证，另一个用于格式化，内部有私有助手。所有方法都有文档记录，新的方法使用经过讨论，有代码审查。

优点：

明确的结构，易于维护，模块化，代码可读且透明。

缺点：

需要团队中的纪律和共识，可能需要额外的审查和结构化时间。

什么是 Swift 中的 extensions，它们如何用于扩展标准和用户定义类型的功能？使用时有哪些风险和注意事项？

答案。

陷阱问题。

常见错误和反模式

实际案例