Swift所有权修饰符指南：borrowing与consuming优化性能与非可复制类型

axiom-ownership-conventions by charleswiltgen/axiom

145 周安装量

795 GitHub Stars

GitHub

安装命令

npx skills add https://github.com/charleswiltgen/axiom --skill axiom-ownership-conventions

代码规范 Swift 性能优化

🇨🇳中文介绍

借用与消耗 —— 参数所有权

用于性能优化和非可复制类型支持的显式所有权修饰符。

何时使用

✅ 在以下情况使用：

传递只读的大型值类型（避免复制）
处理非可复制类型 (~Copyable)
减少 ARC 的保留/释放开销
消耗构建器对象的工厂方法
在性能关键代码中，分析显示复制操作有影响时

❌ 不要在以下情况使用：

简单类型（Int、Bool、小型结构体）
编译器优化已足够（大多数情况）
代码可读性比微优化更重要
不确定性能影响时

快速参考

修饰符	所有权	复制行为	使用场景
(默认)	编译器选择	隐式复制	大多数情况
`borrowing`	调用者保留	仅显式

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

不同上下文下的默认行为

上下文	默认行为	原因
函数参数	`borrowing`	大多数参数是只读的
初始化器参数	`consuming`	通常存储在属性中
属性设置器	`consuming`	值被存储
方法中的 `self`	`borrowing`	方法读取 self

模式 1：只读大型结构体

struct LargeBuffer {
    var data: [UInt8]  // 可能达到兆字节级别
}

// ❌ 默认可能复制
func process(_ buffer: LargeBuffer) -> Int {
    buffer.data.count
}

// ✅ 显式借用 —— 无复制
func process(_ buffer: borrowing LargeBuffer) -> Int {
    buffer.data.count
}

模式 2：消耗型工厂方法

struct Builder {
    var config: Configuration

    // 消耗 self —— 调用后构建器无效
    consuming func build() -> Product {
        Product(config: config)
    }
}

let builder = Builder(config: .default)
let product = builder.build()
// builder 现在无效 —— 如果使用会导致编译错误

模式 3：借用中的显式复制

使用 borrowing 时，复制必须是显式的：

func store(_ value: borrowing LargeValue) {
    // ❌ 错误：无法隐式复制借用参数
    self.cached = value

    // ✅ 显式复制
    self.cached = copy value
}

模式 4：消耗操作符

显式转移所有权：

let data = loadLargeData()
process(consume data)
// data 现在无效 —— 编译器阻止使用

模式 5：非可复制类型

对于 ~Copyable 类型，所有权修饰符是必需的：

struct FileHandle: ~Copyable {
    private let fd: Int32

    init(path: String) throws {
        fd = open(path, O_RDONLY)
        guard fd >= 0 else { throw POSIXError.errno }
    }

    borrowing func read(count: Int) -> Data {
        // 读取而不消耗句柄
        var buffer = [UInt8](repeating: 0, count: count)
        _ = Darwin.read(fd, &buffer, count)
        return Data(buffer)
    }

    consuming func close() {
        Darwin.close(fd)
        // 句柄被消耗 —— 关闭后无法使用
    }

    deinit {
        Darwin.close(fd)
    }
}

// 使用示例
let file = try FileHandle(path: "/tmp/data.txt")
let data = file.read(count: 1024)  // borrowing
file.close()  // consuming —— file 被置为无效

模式 6：减少 ARC 开销

class ExpensiveObject { /* ... */ }

// ❌ 默认：可能保留/释放
func inspect(_ obj: ExpensiveObject) -> String {
    obj.description
}

// ✅ 借用：无 ARC 开销
func inspect(_ obj: borrowing ExpensiveObject) -> String {
    obj.description
}

模式 7：在 self 上的消耗方法

struct Transaction {
    var amount: Decimal
    var recipient: String

    // 提交后，事务被消耗
    consuming func commit() async throws {
        try await sendToServer(self)
        // self 被消耗 —— 无法修改或重用
    }
}

错误 1：过度优化小型类型

// ❌ 不必要 —— Int 是轻量级可复制的
func add(_ a: borrowing Int, _ b: borrowing Int) -> Int {
    a + b
}

// ✅ 让编译器优化
func add(_ a: Int, _ b: Int) -> Int {
    a + b
}

错误 2：忘记显式复制

func cache(_ value: borrowing LargeValue) {
    // ❌ 编译错误
    self.values.append(value)

    // ✅ 需要显式复制
    self.values.append(copy value)
}

错误 3：在借用足够时使用消耗

// ❌ 不必要地消耗 —— 调用者失去访问权限
func validate(_ data: consuming Data) -> Bool {
    data.count > 0
}

// ✅ 对于只读操作使用借用
func validate(_ data: borrowing Data) -> Bool {
    data.count > 0
}

在采用 ~Copyable 前了解其约束：

限制	影响	解决方法
无法存储在 `Array`、`Dictionary`、`Set` 中	集合需要 `Copyable`	使用 `Optional<T>` 包装器或手动管理
无法与大多数泛型一起使用	`<T>` 隐式意味着 `<T: Copyable>`	使用 `<T: ~Copyable>`（需要库支持）
协议一致性受限	大多数协议需要 `Copyable`	使用 `~Copyable` 协议定义
默认无法在闭包中捕获	闭包复制捕获的值	使用 `borrowing` 闭包参数
无存在类型支持	`any ~Copyable` 无效	改用泛型

采用所有权修饰符时的常见编译器错误：

// 错误："无法隐式复制借用参数"
// 修复：添加显式 `copy` 或改为 consuming
func store(_ v: borrowing LargeValue) {
    self.cached = copy v  // ✅ 显式复制
}

// 错误："非可复制类型不能与泛型一起使用"
// 修复：将泛型约束为 ~Copyable
func use<T: ~Copyable>(_ value: borrowing T) { }  // ✅

// 错误："无法消耗借用参数"
// 修复：如果需要所有权转移，改为 consuming
func takeOwnership(_ v: consuming FileHandle) { }  // ✅

// 错误："缺少 'consuming' 或 'borrowing' 修饰符"
// 修复：~Copyable 类型的所有方法都需要显式所有权
struct Token: ~Copyable {
    borrowing func peek() -> String { ... }   // ✅ 显式
    consuming func redeem() { ... }           // ✅ 显式
}

何时不使用 ~Copyable：

如果需要集合存储（数组、字典）
如果需要与现有的泛型 API 一起工作
如果类型需要广泛的协议一致性
对于"一次性使用"语义，优先考虑在常规类型上使用 consuming func 作为更轻量的替代方案

所有权修饰符有帮助的情况

大型结构体（数组、字典、自定义值类型）
紧密循环中的高频函数调用
引用类型中 ARC 开销可测量时
非可复制类型（必需，非可选）

默认行为几乎总是最优的
小型值类型（基本类型、小型结构体）
分析显示无益处的代码
API 稳定性考虑（修饰符影响 ABI）

使用值泛型的固定大小、栈分配数组。无堆分配，无引用计数，无写时复制。

@frozen struct InlineArray<let count: Int, Element> where Element: ~Copyable

let count: Int 是一个值泛型 —— 大小是类型的一部分，在编译时检查。InlineArray<3, Int> 和 InlineArray<4, Int> 是不同的类型。

何时使用 InlineArray

使用 InlineArray	使用 Array
大小在编译时已知	大小在运行时变化
需要零堆分配的热路径	写时复制共享有益处
嵌入其他值类型中	在变量间频繁复制
性能关键的内循环	通用集合需求

// 固定大小，内联存储 —— 无堆分配
var matrix: InlineArray<9, Float> = [1, 0, 0, 0, 1, 0, 0, 0, 1]
matrix[4] = 2.0

// 类型推断适用于数量、元素或两者
let rgb: InlineArray = [0.2, 0.4, 0.8]  // InlineArray<3, Double>

// 赋值时立即复制（无 COW）
var copy = matrix
copy[0] = 99  // matrix[0] 仍为 1

元素连续存储，无开销：

MemoryLayout<InlineArray<3, UInt16>>.size       // 6 (2 字节 × 3)
MemoryLayout<InlineArray<3, UInt16>>.alignment  // 2 (与 UInt16 相同)

InlineArray 支持非可复制元素 —— 支持固定大小的唯一资源集合：

struct Sensor: ~Copyable { var id: Int }
var sensors: InlineArray<4, Sensor> = ...  // 有效：允许 ~Copyable 元素

Span —— 安全的连续内存访问

Span 用编译时强制安全的内存视图替换不安全的指针。零运行时开销。

类型	访问权限	使用场景
`Span<Element>`	只读元素	安全迭代，传递给算法
`MutableSpan<Element>`	读写元素	原地修改，无需复制
`RawSpan`	只读字节	二进制解析，协议解码
`MutableRawSpan`	读写字节	二进制序列化
`OutputSpan`	只写	初始化新集合存储
`UTF8Span`	只读 UTF-8	安全的 Unicode 处理

具有连续存储的容器暴露 .span 和 .mutableSpan：

let array = [1, 2, 3, 4]
let span = array.span  // Span<Int>

var mutable = [10, 20, 30]
var ms = mutable.mutableSpan  // MutableSpan<Int>
ms[0] = 99

生命周期安全 —— 编译时强制

Span 是不可逃逸的 —— 编译器保证它们不能比它们借用的容器存活更久：

// ❌ 无法返回依赖于局部变量的 span
func getSpan() -> Span<UInt8> {
    let array: [UInt8] = Array(repeating: 0, count: 128)
    return array.span  // 编译错误
}

// ❌ 无法在闭包中捕获 span
let span = array.span
let closure = { span.count }  // 编译错误

// ❌ 修改原始容器后无法访问 span
var array = [1, 2, 3]
let span = array.span
array.append(4)
// span[0]  // 编译错误：容器已被修改

这些约束在编译时防止了释放后使用、悬垂指针和重叠修改，且零运行时成本。

Span 与不安全指针对比

| Span | UnsafeBufferPointer
---|---|---
内存安全 | 编译时强制 | 手动，易出错
生命周期跟踪 | 自动，不可逃逸 | 无 —— 可能出现悬垂指针
运行时开销 | 零 | 零
释放后使用 | 不可能 | 常见的崩溃来源

典型示例 —— 二进制解析

func parseHeader(_ data: borrowing [UInt8]) -> Header {
    var raw = data.span.rawSpan  // 数组字节上的 RawSpan
    let magic = raw.unsafeLoadUnaligned(as: UInt32.self)
    raw = raw.extracting(droppingFirst: 4)
    let version = raw.unsafeLoadUnaligned(as: UInt16.self)
    return Header(magic: magic, version: version)
}

替换 UnsafeBufferPointer —— 相同性能，编译时安全
性能关键算法 —— 直接内存访问，无需复制
二进制解析/序列化 —— 字节级访问使用 RawSpan
在函数间传递数据 —— 借用容器，传递 span
UTF-8 处理 —— 安全的字符串字节访问使用 UTF8Span

值泛型允许将整数值作为泛型参数，使大小成为类型系统的一部分：

// `let count: Int` 是一个值泛型参数
struct InlineArray<let count: Int, Element> { ... }

// 不同数量 = 不同类型
let a: InlineArray<3, Int> = [1, 2, 3]
let b: InlineArray<4, Int> = [1, 2, 3, 4]
// a = b  // 编译错误：不同类型

目前仅限于 Int 参数。支持栈分配的固定大小抽象，编译器在编译时验证大小兼容性。

需要显式所有权吗？
├─ 处理 ~Copyable 类型？
│  └─ 是 → 必需 (borrowing/consuming)
├─ 固定大小集合，无堆分配？
│  └─ 是 → InlineArray<let count, Element>
├─ 需要安全的类似指针的连续内存访问？
│  ├─ 只读？ → Span<Element>
│  ├─ 可变？ → MutableSpan<Element>
│  └─ 原始字节？ → RawSpan / MutableRawSpan
├─ 大型值类型频繁传递？
│  ├─ 只读？ → borrowing
│  └─ 最终使用？ → consuming
├─ 分析器中可见 ARC 开销？
│  ├─ 只读？ → borrowing
│  └─ 转移所有权？ → consuming
└─ 否则 → 让编译器选择

Swift Evolution : SE-0377, SE-0453 (Span), SE-0451 (InlineArray), SE-0452 (值泛型)

WWDC : 2024-10170, 2025-245, 2025-312

文档 : /swift/inlinearray, /swift/span

技能 : axiom-swift-performance, axiom-swift-concurrency

🇺🇸English

borrowing & consuming — Parameter Ownership

Explicit ownership modifiers for performance optimization and noncopyable type support.

When to Use

✅ Use when:

Large value types being passed read-only (avoid copies)
Working with noncopyable types (~Copyable)
Reducing ARC retain/release traffic
Factory methods that consume builder objects
Performance-critical code where copies show in profiling

❌ Don't use when:

Simple types (Int, Bool, small structs)
Compiler optimization is sufficient (most cases)
Readability matters more than micro-optimization
You're not certain about the performance impact

Quick Reference

Modifier	Ownership	Copies	Use Case
(default)	Compiler chooses	Implicit	Most cases
`borrowing`	Caller keeps	Explicit `copy` only	Read-only, large types
`consuming`	Caller transfers	None needed	Final use, factories
`inout`	Caller keeps, mutable	None	Modify in place

Default Behavior by Context

Context	Default	Reason
Function parameters	`borrowing`	Most params are read-only
Initializer parameters	`consuming`	Usually stored in properties
Property setters	`consuming`	Value is stored
Method `self`	`borrowing`	Methods read self

Patterns

Pattern 1: Read-Only Large Struct

struct LargeBuffer {
    var data: [UInt8]  // Could be megabytes
}

// ❌ Default may copy
func process(_ buffer: LargeBuffer) -> Int {
    buffer.data.count
}

// ✅ Explicit borrow — no copy
func process(_ buffer: borrowing LargeBuffer) -> Int {
    buffer.data.count
}

Pattern 2: Consuming Factory

struct Builder {
    var config: Configuration

    // Consumes self — builder invalid after call
    consuming func build() -> Product {
        Product(config: config)
    }
}

let builder = Builder(config: .default)
let product = builder.build()
// builder is now invalid — compiler error if used

Pattern 3: Explicit Copy in Borrowing

With borrowing, copies must be explicit:

func store(_ value: borrowing LargeValue) {
    // ❌ Error: Cannot implicitly copy borrowing parameter
    self.cached = value

    // ✅ Explicit copy
    self.cached = copy value
}

Pattern 4: Consume Operator

Transfer ownership explicitly:

let data = loadLargeData()
process(consume data)
// data is now invalid — compiler prevents use

Pattern 5: Noncopyable Type

For ~Copyable types, ownership modifiers are required :

struct FileHandle: ~Copyable {
    private let fd: Int32

    init(path: String) throws {
        fd = open(path, O_RDONLY)
        guard fd >= 0 else { throw POSIXError.errno }
    }

    borrowing func read(count: Int) -> Data {
        // Read without consuming handle
        var buffer = [UInt8](repeating: 0, count: count)
        _ = Darwin.read(fd, &buffer, count)
        return Data(buffer)
    }

    consuming func close() {
        Darwin.close(fd)
        // Handle consumed — can't use after close()
    }

    deinit {
        Darwin.close(fd)
    }
}

// Usage
let file = try FileHandle(path: "/tmp/data.txt")
let data = file.read(count: 1024)  // borrowing
file.close()  // consuming — file invalidated

Pattern 6: Reducing ARC Traffic

class ExpensiveObject { /* ... */ }

// ❌ Default: May retain/release
func inspect(_ obj: ExpensiveObject) -> String {
    obj.description
}

// ✅ Borrowing: No ARC traffic
func inspect(_ obj: borrowing ExpensiveObject) -> String {
    obj.description
}

Pattern 7: Consuming Method on Self

struct Transaction {
    var amount: Decimal
    var recipient: String

    // After commit, transaction is consumed
    consuming func commit() async throws {
        try await sendToServer(self)
        // self consumed — can't modify or reuse
    }
}

Common Mistakes

Mistake 1: Over-Optimizing Small Types

// ❌ Unnecessary — Int is trivially copyable
func add(_ a: borrowing Int, _ b: borrowing Int) -> Int {
    a + b
}

// ✅ Let compiler optimize
func add(_ a: Int, _ b: Int) -> Int {
    a + b
}

Mistake 2: Forgetting Explicit Copy

func cache(_ value: borrowing LargeValue) {
    // ❌ Compile error
    self.values.append(value)

    // ✅ Explicit copy required
    self.values.append(copy value)
}

Mistake 3: Consuming When Borrowing Suffices

// ❌ Consumes unnecessarily — caller loses access
func validate(_ data: consuming Data) -> Bool {
    data.count > 0
}

// ✅ Borrow for read-only
func validate(_ data: borrowing Data) -> Bool {
    data.count > 0
}

~Copyable Limitations

Know the constraints before adopting ~Copyable:

Limitation	Impact	Workaround
Can't store in `Array`, `Dictionary`, `Set`	Collections require `Copyable`	Use `Optional<T>` wrapper or manage manually
Can't use with most generics	`<T>` implicitly means `<T: Copyable>`	Use `<T: ~Copyable>` (requires library support)

Common compiler errors when adopting ownership modifiers:

// Error: "Cannot implicitly copy a borrowing parameter"
// Fix: Add explicit `copy` or change to consuming
func store(_ v: borrowing LargeValue) {
    self.cached = copy v  // ✅ Explicit copy
}

// Error: "Noncopyable type cannot be used with generic"
// Fix: Constrain generic to ~Copyable
func use<T: ~Copyable>(_ value: borrowing T) { }  // ✅

// Error: "Cannot consume a borrowing parameter"
// Fix: Change to consuming if you need ownership transfer
func takeOwnership(_ v: consuming FileHandle) { }  // ✅

// Error: "Missing 'consuming' or 'borrowing' modifier"
// Fix: ~Copyable types require explicit ownership on all methods
struct Token: ~Copyable {
    borrowing func peek() -> String { ... }   // ✅ Explicit
    consuming func redeem() { ... }           // ✅ Explicit
}

When NOT to use ~Copyable:

If you need collection storage (arrays, dictionaries)
If you need to work with existing generic APIs
If the type needs broad protocol conformance
Prefer consuming func on regular types as a lighter alternative for "use once" semantics

Performance Considerations

When Ownership Modifiers Help

Large structs (arrays, dictionaries, custom value types)
High-frequency function calls in tight loops
Reference types where ARC traffic is measurable
Noncopyable types (required, not optional)

When to Skip

Default behavior is almost always optimal
Small value types (primitives, small structs)
Code where profiling shows no benefit
API stability concerns (modifiers affect ABI)

InlineArray

Fixed-size, stack-allocated array using value generics. No heap allocation, no reference counting, no copy-on-write.

Declaration

@frozen struct InlineArray<let count: Int, Element> where Element: ~Copyable

The let count: Int is a value generic — the size is part of the type, checked at compile time. InlineArray<3, Int> and InlineArray<4, Int> are different types.

When to Use InlineArray

Use InlineArray	Use Array
Size known at compile time	Size changes at runtime
Hot path needing zero heap allocation	Copy-on-write sharing is beneficial
Embedded in other value types	Frequently copied between variables
Performance-critical inner loops	General-purpose collection needs

Canonical Example

// Fixed-size, inline storage — no heap allocation
var matrix: InlineArray<9, Float> = [1, 0, 0, 0, 1, 0, 0, 0, 1]
matrix[4] = 2.0

// Type inference works for count, element, or both
let rgb: InlineArray = [0.2, 0.4, 0.8]  // InlineArray<3, Double>

// Eager copy on assignment (no COW)
var copy = matrix
copy[0] = 99  // matrix[0] still 1

Memory Layout

Elements are stored contiguously with no overhead:

MemoryLayout<InlineArray<3, UInt16>>.size       // 6 (2 bytes × 3)
MemoryLayout<InlineArray<3, UInt16>>.alignment  // 2 (same as UInt16)

~Copyable Integration

InlineArray supports noncopyable elements — enables fixed-size collections of unique resources:

struct Sensor: ~Copyable { var id: Int }
var sensors: InlineArray<4, Sensor> = ...  // Valid: ~Copyable elements allowed

Span — Safe Contiguous Memory Access

Span replaces unsafe pointers with compile-time-enforced safe memory views. Zero runtime overhead.

The Span Family

Type	Access	Use Case
`Span<Element>`	Read-only elements	Safe iteration, passing to algorithms
`MutableSpan<Element>`	Read-write elements	In-place mutation without copies
`RawSpan`	Read-only bytes	Binary parsing, protocol decoding
`MutableRawSpan`	Read-write bytes	Binary serialization
`OutputSpan`	Write-only

Accessing Spans

Containers with contiguous storage expose .span and .mutableSpan:

let array = [1, 2, 3, 4]
let span = array.span  // Span<Int>

var mutable = [10, 20, 30]
var ms = mutable.mutableSpan  // MutableSpan<Int>
ms[0] = 99

Lifetime Safety — Compile-Time Enforcement

Spans are non-escapable — the compiler guarantees they cannot outlive the container they borrow from:

// ❌ Cannot return span that depends on local variable
func getSpan() -> Span<UInt8> {
    let array: [UInt8] = Array(repeating: 0, count: 128)
    return array.span  // Compile error
}

// ❌ Cannot capture span in closure
let span = array.span
let closure = { span.count }  // Compile error

// ❌ Cannot access span after mutating original
var array = [1, 2, 3]
let span = array.span
array.append(4)
// span[0]  // Compile error: container was modified

These constraints prevent use-after-free, dangling pointers, and overlapping mutation at compile time with zero runtime cost.

Span vs Unsafe Pointers

| Span | UnsafeBufferPointer
---|---|---
Memory safety | Compile-time enforced | Manual, error-prone
Lifetime tracking | Automatic, non-escapable | None — dangling pointers possible
Runtime overhead | Zero | Zero
Use-after-free | Impossible | Common source of crashes

Canonical Example — Binary Parsing

func parseHeader(_ data: borrowing [UInt8]) -> Header {
    var raw = data.span.rawSpan  // RawSpan over the array's bytes
    let magic = raw.unsafeLoadUnaligned(as: UInt32.self)
    raw = raw.extracting(droppingFirst: 4)
    let version = raw.unsafeLoadUnaligned(as: UInt16.self)
    return Header(magic: magic, version: version)
}

When to Use Span

ReplaceUnsafeBufferPointer — same performance, compile-time safety
Performance-critical algorithms — direct memory access without copying
Binary parsing/serialization — RawSpan for byte-level access
Passing data between functions — borrow the container, pass the span
UTF-8 processing — UTF8Span for safe string byte access

Value Generics

Value generics allow integer values as generic parameters, making sizes part of the type system:

// `let count: Int` is a value generic parameter
struct InlineArray<let count: Int, Element> { ... }

// Different counts = different types
let a: InlineArray<3, Int> = [1, 2, 3]
let b: InlineArray<4, Int> = [1, 2, 3, 4]
// a = b  // Compile error: different types

Currently limited to Int parameters. Enables stack-allocated, fixed-size abstractions where the compiler verifies size compatibility at compile time.

Decision Tree

Need explicit ownership?
├─ Working with ~Copyable type?
│  └─ Yes → Required (borrowing/consuming)
├─ Fixed-size collection, no heap allocation?
│  └─ Yes → InlineArray<let count, Element>
├─ Need safe pointer-like access to contiguous memory?
│  ├─ Read-only? → Span<Element>
│  ├─ Mutable? → MutableSpan<Element>
│  └─ Raw bytes? → RawSpan / MutableRawSpan
├─ Large value type passed frequently?
│  ├─ Read-only? → borrowing
│  └─ Final use? → consuming
├─ ARC traffic visible in profiler?
│  ├─ Read-only? → borrowing
│  └─ Transferring ownership? → consuming
└─ Otherwise → Let compiler choose

Resources

Swift Evolution : SE-0377, SE-0453 (Span), SE-0451 (InlineArray), SE-0452 (value generics)

WWDC : 2024-10170, 2025-245, 2025-312

Docs : /swift/inlinearray, /swift/span

Skills : axiom-swift-performance, axiom-swift-concurrency

Weekly Installs

Repository

charleswiltgen/axiom

GitHub Stars

606

First Seen

Jan 21, 2026

Security Audits

Gen Agent Trust HubPass SocketPass SnykPass

Installed on

opencode73

claude-code69

codex68

gemini-cli66

cursor66

github-copilot63

TanStack Query v5 完全指南：React 数据管理、乐观更新、离线支持

2,500 周安装

Swift所有权修饰符指南：borrowing与consuming优化性能与非可复制类型

🇨🇳中文介绍

借用与消耗 —— 参数所有权

何时使用

快速参考

相关 Skills

不同上下文下的默认行为

模式

模式 1：只读大型结构体

模式 2：消耗型工厂方法

模式 3：借用中的显式复制

模式 4：消耗操作符

模式 5：非可复制类型

模式 6：减少 ARC 开销

模式 7：在 self 上的消耗方法

常见错误

错误 1：过度优化小型类型

错误 2：忘记显式复制

错误 3：在借用足够时使用消耗

~Copyable 限制

性能考虑

所有权修饰符有帮助的情况

何时跳过

InlineArray

声明

何时使用 InlineArray

典型示例

内存布局

~Copyable 集成

Span —— 安全的连续内存访问

Span 家族

访问 Span

生命周期安全 —— 编译时强制

Span 与不安全指针对比

典型示例 —— 二进制解析

何时使用 Span

值泛型

决策树

资源

🇺🇸English

borrowing & consuming — Parameter Ownership

When to Use

Quick Reference

Default Behavior by Context

Patterns

Pattern 1: Read-Only Large Struct

Pattern 2: Consuming Factory

Pattern 3: Explicit Copy in Borrowing

Pattern 4: Consume Operator

Pattern 5: Noncopyable Type

Pattern 6: Reducing ARC Traffic

Pattern 7: Consuming Method on Self

Common Mistakes

Mistake 1: Over-Optimizing Small Types

Mistake 2: Forgetting Explicit Copy

Mistake 3: Consuming When Borrowing Suffices

~Copyable Limitations

Performance Considerations

When Ownership Modifiers Help

When to Skip

InlineArray

Declaration

When to Use InlineArray

Canonical Example

Memory Layout

~Copyable Integration

Span — Safe Contiguous Memory Access

The Span Family

Accessing Spans

Lifetime Safety — Compile-Time Enforcement

Span vs Unsafe Pointers

Canonical Example — Binary Parsing

When to Use Span

Value Generics

Decision Tree

Resources

最新 Skills