@inlinable 属性指示 Swift 编译器将函数的实现序列化到模块接口文件中，允许在编译时将函数体直接复制到客户端模块，以启用激进的优化，如泛型特化和常量折叠。然而，由于内联代码必须解析客户端编译单元内的所有符号引用，被 @inlinable 函数访问的任何 internal 类型、函数或属性必须标记为 @usableFromInline，这样可以在不将其发布为公共 API 的情况下向编译器暴露它们。
// 在一个弹性框架模块内 @usableFromInline internal struct InternalBuffer { @usableFromInline var storage: [Int] } @inlinable public func fastSum(_ buffer: InternalBuffer) -> Int { // 由于 @usableFromInline 可以访问内部存储 return buffer.storage.reduce(0, +) }
这种组合允许库作者提供零成本抽象，其中泛型代码在客户端二进制文件中被单态化，尽管这牺牲了一些 ABI 灵活性，因为函数体成为稳定二进制接口的一部分。
一个开发高吞吐量机器学习框架的团队需要向客户端应用程序公开一个泛型矩阵乘法函数 matmul<T: Numeric>，但剖析显示跨模块函数调用开销和缺乏特化使得性能相比手写循环降低了40%。该库作为二进制 Swift 包发布，因此客户端无法进行源级优化。
一种方法是使所有工具类型和实现函数 public，暴露内部缓冲管理和步幅计算的每一个细节。虽然这允许进行内联，但这将锁定团队永远维护这些特定的内部类型作为稳定 API，防止将来重构，并且让公共接口充斥实现细节，消费者绝不应该直接触及。
另一个考虑的选项是使用 @inline(__always)，这会在同一模块内激进地内联代码，但不会将函数体导出到其他模块；这将保持 API 的清晰，但不会允许客户端编译器为特定数字类型（如 Float16 或 Double）特化泛型 T，使得运行时调度开销仍然存在，未能达到性能目标。
最终，工程师们用 @inlinable 标记了入口点，并用 @usableFromInline 注释了内部缓冲结构和算术辅助功能。这个策略向编译器揭示了足够的实现细节，以允许客户端调用点的完全单态化和内联，同时将符号排除在公共文档之外。结果是客户端应用程序实现了与手动展开的 C 代码相同的性能，尽管由于跨模块代码重复，框架的二进制大小略有增加，团队接受了补丁函数将需要客户端重新编译。
@inlinable 和 @inline(__always) 在跨模块边界上的根本区别是什么？
@inlinable 是一个模块接口契约，它将函数体写入 .swiftinterface 文件，允许编译器在依赖模块的编译期间直接发出实现，这对跨模块泛型特化至关重要。相比之下，@inline(__always) 仅仅是对本地编译单元的优化提示；它指示优化器在模块内扁平化调用堆栈，但并不将函数体提供给外部编译器，这意味着客户端模块仍通过弹性间接调动该函数，无法消除泛型调度开销。
为什么 Swift 要求 @usableFromInline 对 @inlinable 函数引用的内部符号，而不是简单推断可见性？
当一个函数被内联到客户端模块时，编译器必须在调用点生成该代码的具体机器指令，这需要每个引用实体的完整类型元数据和符号地址；internal 符号故意不包括在模块接口中，以强制执行封装。 @usableFromInline 作为一个特殊的仅编译器可见性级别，在接口文件中暴露符号定义，而不使其对客户端源代码可访问，满足代码生成要求，同时维护源级隐私，防止意外的 API 泄漏。
采用 @inlinable 如何影响 Swift 库的 ABI 稳定性和二进制大小特征？
将函数标记为 @inlinable 会将其实现嵌入到库的 ABI 中，这意味着对函数体的任何更改，例如修复错误或改善算法，都构成了破坏二进制的更改，需要所有客户端模块重新编译以观察更新，这与弹性函数不同，后者的实现可以独立交换。此外，由于编译器在所有客户端二进制文件的每个调用点复制函数体，而不是引用一个共享库地址，@inlinable 显著增加了最终应用程序的整体二进制大小，使其不适合大型、调用频率低的工具函数。