Rust/Go 语言惯用设计模式

• Go 接口隐式实现
• 小接口哲学
• 接口组合

• Go 接口隐式实现：Go 接口是结构性的，类型只要实现接口的方法即满足接口（无需显式声明 implements）。隐式实现让类型自动满足它能力匹配的接口，无需预先规划。
• 小接口：因为隐式实现，Go 鼓励定义小接口（1-2 个方法），如 io.Reader（Read）、io.Writer（Write）、io.Closer（Close）。小接口表达单一能力，易实现、易组合。
• 接口组合：Go 的接口可以嵌入（embedding）组合成大接口，如 io.ReadWriter = io.Reader + io.Writer。小接口通过组合构成更丰富的能力，满足"接口即最小契约"。
• 收益：隐式实现让类型无需知悉接口，小接口让实现简单、组合灵活，接口组合复用能力。这是 Go 接口设计的核心哲学。
• 结论：Go 隐式实现让类型自动满足接口，因此鼓励小接口并通过嵌入组合，小接口易实现、易组合，接口组合表达复合能力。

Go 接口结构性隐式实现，无继承声明，故倡导小接口（单一能力）并支持嵌入组合。小接口易实现、可组合，构成 Go 接口哲学。

• context.Context 接口
• 取消与超时传播
• 请求范围值传递

• context.Context：Go 中跨 API 边界传递取消信号、超时、截止时间、请求范围值的载具。通过 context.WithCancel、context.WithTimeout、context.WithDeadline、context.WithValue 派生。
• 取消传播：WithCancel 创建可取消的 context，父 context 取消时子 context 级联取消（传播），调用方通过 ctx.Done() 通道感知取消，被调用方据此停止工作，实现"取消整条调用链"。
• 超时：WithTimeout(ctx, d) 设置超时，超时后 context 自动取消（ctx.Done() 关闭），被调用方停止，避免无限等待。
• 请求范围值：WithValue(ctx, key, val) 携带请求范围值（如 traceId、用户信息），在调用链中传递，子 context 可读取。
• 使用规范：context 作为第一个参数传递；不存不可取消的长期 context；CancelFunc 要 defer 调用释放。
• 结论：context 通过派生与 Done 传播取消/超时到整条调用链，用 WithValue 传递请求范围值，是 Go 并发控制的标准工具。

context 用派生 context 传播取消/超时（Done 通道感知），WithValue 传递请求范围值。调用链中逐层传递，实现统一取消与超时控制。

• channel（通信）适用场景
• mutex（互斥）适用场景
• atomic（原子）适用场景

• channel：适合协程间通信与协作、数据流、生产者-消费者、扇入扇出、信号通知。channel 传递值，天然同步，适合"数据在协程间流动"。
• mutex：适合保护共享数据的临界区（多个协程读写同一数据结构），如计数器、缓存、map 的并发访问。当"共享可变状态 + 需要事务性操作"时用锁。
• atomic：适合简单原子操作（计数器、标志位、无锁状态），如 atomic.AddInt64、比较交换。性能好、无锁，但只适用于简单标量操作。
• 为什么不通过共享内存通信并非万能：channel 虽好，但"通过通信共享内存"是哲学，不是所有场景都适用。复杂共享状态（如大缓存、数据库连接池）用 channel 反而笨拙，用 mutex 更直接；channel 有开销（goroutine 调度、阻塞），简单计数器用 atomic 更高效。选型要按场景：数据流用 channel、共享状态用 mutex、简单标量用 atomic。
• 结论：channel 通信、mutex 保护共享数据、atomic 简单原子操作，三者按场景选型，channel 并非万能。

选型依据：数据流/协作用 channel，共享可变状态用 mutex，简单标量用 atomic。channel 哲学不万能，复杂共享状态用锁更合适。

• Send/Sync 定义
• 所有权与借用检查
• 编译期数据竞争保证与手动实现

• Send：类型可移动到其他线程（T: Send 表示所有权可在线程间转移）。Sync：类型可被多个线程同时引用（&T: Send，即共享引用可跨线程，如 &T 可被并发读）。
• 所有权与数据竞争：Rust 的所有权 + 借用规则在编译期保证"同一时刻要么独占可变引用，要么多个共享引用"，从根上消除数据竞争；配合 Send/Sync，编译器在编译期检查"跨线程移动/共享"是否安全，否则编译失败。数据竞争在编译期暴露。
• 何时手动实现：绝大多数类型自动实现 Send/Sync（若字段都 Send/Sync）。需要手动实现（unsafe impl）的场景：封装了非 Send/Sync 的底层资源（如裸指针、FFI）但保证安全的类型，或包装了线程本地/单线程类型但有意提供跨线程能力的类型。手动实现需保证线程安全，否则是 UB。
• 结论：Send/Sync 定义线程可移动/共享性，所有权模型让数据竞争在编译期暴露；自定义类型通常自动实现，仅封装不安全底层资源时才需手动实现（unsafe impl）。

Send=可跨线程移动，Sync=可跨线程共享引用。所有权 + 借用 + Send/Sync 让并发安全在编译期保证。手动 impl 仅用于封装不安全资源时。

• 接受接口返回结构体
• 接口解耦与可测试
• 返回结构体灵活性

• "接受接口返回结构体"（Accept interfaces, return structs）：函数参数用接口（接收实现该接口的类型，解耦），返回值用具体结构体（不返回接口，避免接口过度抽象）。
• 接受接口：参数声明为接口，调用方可传入任意实现，灵活、解耦，便于 mock 测试。
• 返回结构体：返回值用具体类型，因为返回接口会让调用方依赖接口抽象、且接口会随返回类型膨胀（"接口返回"通常是反模式）。返回结构体明确、具体，调用方直接用。
• 可测试性：参数接受接口，测试时可传入 mock 实现（fake 接口），无需真实依赖，隔离测试；返回结构体让调用方直接断言具体类型，测试简单。
• 结论：接受接口（参数解耦、可 mock）返回结构体（具体明确）是 Go 的惯用设计准则，提升解耦与可测试性。

参数用接口（解耦、可 mock），返回用结构体（具体明确）。提升可测试性：mock 接口注入，直接断言具体返回类型。

• Result<T,E> 表达错误
• ? 操作符传播
• 显式错误传播

• Result<T,E>：Rust 函数返回 Result<T,E>，成功 Ok(T)，失败 Err(E)。错误作为返回值，类型强制调用方处理。
• ? 操作符：? 用在返回 Result 的函数中，x? 若 x 是 Ok(v) 则解出 v，若是 Err(e) 则直接返回该错误（自动转换为函数返回的错误类型）。? 让错误显式传播到调用方。
• 强制错误传播：函数必须处理 Result（用 ? 传播、match 处理、unwrap 等），无法静默忽略错误。? 简化了"传播错误"的样板代码，保持错误显式。
• 对比 Go：Go 用 if err != nil { return err } 显式判断，Rust 用 ? 简化，两者都强制错误显式传播（不吞错）。
• 结论：Result 用类型表达错误，? 操作符把错误显式传播到调用方（Ok 解出、Err 返回），强制错误处理、不可忽略。

Result 类型表达错误，? 在 Ok 解出值、在 Err 提前返回，把错误显式传播到调用方。强制错误处理，避免静默吞错。

• error 作为值显式返回
• errors.Is/As 比较与类型断言
• %w 包装链

• error 作为值：Go 的错误是返回值（error 接口），函数显式返回 error，调用方用 if err != nil 判断。错误是"值"而非异常，显式、可传播、可处理。
• 包装链：用 fmt.Errorf("...: %w", err) 包装错误，%w 保持原错误可被 errors.Is/errors.As 追踪，形成错误链（包装链）。
• errors.Is：判断错误链中是否包含某个特定错误（等于比较），用 errors.Is(err, ErrNotFound) 检查特定哨兵错误，即使被包装也能找到。
• errors.As：把错误链中的错误类型断言为目标类型，errors.As(err, &target) 提取特定类型的错误（如自定义错误类型），用于类型化处理。
• 结论：error 作为值显式返回，%w 包装形成错误链，errors.Is 判断特定错误、errors.As 提取特定类型，让包装后的错误可追溯、可分类处理。

error 是值显式返回，%w 包装保持链，errors.Is 比较哨兵错误、errors.As 类型断言提取。错误链可追踪、可分类。

• fan-out（分发）与 fan-in（合并）
• worker pool 模式
• channel 实现

• fan-out：从一个输入 channel 分发任务到多个 goroutine（多个 worker 并发处理），提高并行度。
• fan-in：从多个 goroutine 合并结果到一个输出 channel（多个源汇聚到接收端），用 sync.WaitGroup 等待所有 worker 完成后关闭输出 channel。
• worker pool：固定数量 worker goroutine 从任务 channel 取任务处理，结果写结果 channel，用 sync.WaitGroup 协调。限制并发数、复用 goroutine、控制资源。
• 惯用实现：输入 channel（任务）→ 多个 worker（各一个 goroutine 从输入取任务处理）→ 输出 channel（结果），关闭逻辑用 WaitGroup 保证"所有 worker 完成后关闭输出 channel，接收方 for-range 结束"。
• 结论：fan-out 用多个 goroutine 分发处理，fan-in 用 WaitGroup 合并结果关 channel，worker pool 用固定 worker 控制并发，是 Go 并发惯用模式。

fan-out 分发、fan-in 合并（WaitGroup 关 channel），worker pool 固定并发。都是 channel + goroutine 的惯用组合。

• sync.Pool 对象复用
• 降低分配与 GC
• 适用场景与限制

• sync.Pool：Go 提供的对象池，用于复用高频创建的对象，通过 Get()/Put() 借出与归还，减少频繁分配。
• 降低 GC 压力：高频创建对象会导致大量内存分配，触发 GC 频繁回收。sync.Pool 复用对象，减少分配次数，从而降低 GC 压力（少分配、少回收）。
• 机制：sync.Pool 每个 P 有本地池，Get() 从本地取（无则 new），Put() 归还；GC 时池中对象可能被清空（不保证保留），所以 sync.Pool 用于"可重建的临时对象"（如 buffer），不用于长期状态。
• 适用场景：高频分配/释放的临时对象（如 bytes.Buffer、解码中间结构），典型如 json 解码、网络缓冲。限制：池不保证对象存活、内容需重置。
• 结论：sync.Pool 复用高频临时对象，减少分配与 GC，降低 GC 压力，适合作一次性临时对象池。

sync.Pool 复用高频对象，减少内存分配，降低 GC 压力。用于可重建临时对象（buffer），GC 会清空池，不保证对象存活。

• 结构体嵌入（组合）
• 方法提升（promotion）
• 接口满足（自动）

• 结构体嵌入：Go 的结构体可以嵌入其他结构体（匿名嵌入字段），得到被嵌入类型的所有字段与方法，实现组合式复用（组合优于继承）。
• 方法提升：嵌入的结构体，其方法被"提升"到外层结构体，外层可以直接调用内层的方法（如 type Reader struct{ *bufio.Reader }，Reader 可直接调用 bufio.Reader 的方法）。字段也提升。
• 接口满足：因为方法提升，外层结构体自动满足被嵌入类型实现的接口（若提升的方法构成接口），可当作接口使用。如 io.ReadCloser 由嵌入的 io.Reader（Read）+ io.Closer（Close）组合满足。
• 组合式复用：嵌入让外层复用内层能力（转发方法），无需继承，比继承更灵活（可嵌入多个类型）。覆盖可通过定义同名方法。
• 结论：嵌入实现组合复用，方法提升让外层直接调用内层方法，接口满足自动继承，构成 Go 的组合式设计。

嵌入=组合复用，方法提升=外层可调内层方法，接口满足=自动实现接口。嵌入比继承灵活，是 Go 组合式设计核心。

• Functional Options
• 可变长函数参数配置
• 与 Builder 差异

• Functional Options：用可变长函数参数（...Option）配置对象构造，每个 Option 是一个函数，修改配置。如 NewServer(opts ...Option)，调用方传 ServerTimeout(5*time.Second) 等 Options。
• 实现：Option 是 func(*Config)，构造时遍历 Options 应用到配置，默认值 + 覆盖。可扩展——新增配置项只需新增一个 Option 函数，不改构造器签名，向后兼容。
• 优点：可读性好、可选参数、可扩展、向后兼容（新增选项不破坏现有调用）。
• 与 Builder 差异：Functional Options 用"函数参数"配置（Go 惯用），Builder 用"链式方法"配置（Java 惯用）。Functional Options 更简洁、原生支持默认值、不引入额外类型；Builder 更显式、可校验、可中途构建。Go 无重载，Functional Options 是惯用替代。
• 结论：Functional Options 用可变长函数参数配置构造，可扩展、向后兼容；与 Builder 都是"可选参数配置"，但实现不同（函数参数 vs 链式方法）。

Functional Options 用函数参数配置，可扩展、向后兼容；Builder 用链式方法。Go 无重载，Functional Options 是配置构造的惯用方式。

• 内部可变性
• Cell vs RefCell
• 单线程限制

• 内部可变性（interior mutability）：让不可变引用（&T）也能修改内部数据，通过内部可变性类型（Cell/RefCell）实现，是 Rust 所有权模型的补充。
• Cell：适用于 Copy 类型，提供 get()/set() 直接取值/赋值，无借用检查（重入安全），限制为 Copy 类型。
• RefCell：适用于非 Copy 类型，提供 borrow_mut() 获取可变借用、borrow() 获取共享借用，运行时检查借用规则（同一时刻可变借用与共享借用不共存，违反则 panic）。可将借用检查从编译期推迟到运行时。
• 单线程限制：Cell/RefCell 是单线程内部可变性（非 Sync），不能跨线程共享，需配合 Mutex/RwLock 或 Arc 才能跨线程。用于单线程内"需要在不可变接口下修改"的场景。
• 结论：Cell/RefCell 实现单线程内部可变性，Cell 用于 Copy 类型（get/set），RefCell 用于非 Copy 类型（运行时借用检查），两者单线程内安全。

Cell/RefCell 让 &T 也能改内部（内部可变性）。Cell 适合 Copy（get/set），RefCell 非 Copy（运行时借用检查）。单线程内使用，跨线程用 Mutex。

• trait 定义行为
• trait bound 泛型约束
• 组合与实现

• trait：Rust 定义行为的抽象（类似接口），trait Foo { fn bar(); }，trait 可包含方法、关联类型、默认实现。类型实现 trait 获得行为。
• trait bound：泛型约束用 trait bound，fn f<T: Foo>(x: T) 表示 T 必须实现 Foo。trait bound 约束泛型的接口能力，替代"接口 + 泛型"。
• 替代传统接口：trait 替代接口（抽象行为），trait bound 替代泛型约束（约束类型必须实现某 trait），比传统接口更强大（可组合多个 bound、带默认实现、关联类型、静态分派）。
• 组合：T: Foo + Bar 组合多个 trait，约束类型同时实现多个接口；impl Trait 语法糖。trait 支持派生（derive）、动态分派（dyn Trait）。
• 结论：trait 定义行为（替代接口），trait bound 约束泛型（替代泛型约束），trait 组合能力强、支持静态分派，是 Rust 的抽象与约束机制。

trait 定义行为，trait bound 约束泛型参数，替代接口与泛型约束。trait 可组合、默认实现、静态分派，比传统接口更强大。

• RAII 概念
• Drop trait 析构
• 确定性释放

• RAII（Resource Acquisition Is Initialization）：资源在构造时获取，在析构时释放（作用域结束）。Rust 用所有权 + Drop trait 实现。
• Drop trait：实现 Drop 的 drop(&mut self) 自定义析构逻辑（释放文件、解锁、归还资源）。对象离开作用域时自动调用 drop，释放资源。
• 确定性释放：Rust 的作用域决定对象生命周期，对象离开作用域立即 drop，无需手动释放、无需 GC 垃圾回收，资源在确定位置、确定时机释放。文件、锁、内存（Box/String）都在作用域结束时自动释放。
• 对比：手动管理（C 的 free）易泄漏；GC 的释放不确定。Rust RAII 让资源释放确定性、自动、作用域绑定。
• 结论：Rust 用所有权 + Drop trait 实现 RAII，资源在作用域结束时确定性释放，文件/锁/内存自动释放，无需手动管理。

RAII 构造获取、析构释放。Drop trait 自定义析构，对象离开作用域自动 drop，资源确定性释放，避免泄漏与 GC 不确定性。

• Rc/Arc 共享所有权
• 引用计数与借用
• 内部可变性配合

• 共享所有权：Rust 默认单一所有权，Rc（单线程）/Arc（多线程原子）提供共享所有权——多个 Rc/Arc 指向同一数据，引用计数管理，无引用时释放。Arc 是线程安全的 Rc（原子计数）。
• 与借用检查器协作：Rc/Arc 解决"多个所有者"问题，但数据本身不可变（默认），要修改共享数据需配合内部可变性（RefCell/Cell 单线程，Mutex/RwLock 多线程），如 Rc<RefCell<T>>、Arc<Mutex<T>>。
• 借用检查：Rc/Arc 的 clone 增加引用计数，不违反借用规则（共享引用）；Rc 非 Send（单线程），Arc 是 Send+Sync（可跨线程）。借用检查器在编译期保证 Rc/Arc 的安全使用。
• 建模：共享所有权用 Rc/Arc，可变共享数据用内部可变性（Rc<RefCell<>>、Arc<Mutex<>>），配合借用检查器保证安全。
• 结论：Rc/Arc 提供共享所有权（引用计数），配合内部可变性（RefCell/Mutex）建模可变共享数据，借用检查器在编译期保证其安全。

Rc/Arc 共享所有权（引用计数），默认不可变，可变需配合内部可变性（Rc<RefCell<>>、Arc<Mutex<>>）。借用检查器保证安全。

• 所有权（所有权单一）
• 借用规则（可变/不可变）
• 编译期内存安全

• 所有权：每个值有且只有一个所有者，所有者离开作用域时值被释放。单一所有权保证内存确定性释放（无 GC 回收器）。
• 借用规则：通过引用借用而不转移所有权——同一时刻要么多个不可变借用（&T），要么一个可变借用（&mut T），不能同时存在可变与不可变借用。借用规则在编译期检查，杜绝悬垂引用、数据竞争、use-after-free。
• 替代 GC：Rust 无垃圾回收，靠所有权 + 作用域在编译期确定内存释放时机，内存安全且无 GC 停顿。
• 替代裸指针：借用检查在编译期保证引用安全（不悬垂、不越界），大部分场景无需裸指针（unsafe 才用裸指针，且需人工保证安全）。
• 结论：所有权 + 借用规则在编译期保证内存安全（无悬垂、无数据竞争、确定性释放），替代 GC 与裸指针，兼顾性能与安全。

所有权单一（确定性释放）+ 借用规则（编译期检查）实现内存安全，无需 GC（性能）与裸指针（安全）。这是 Rust 的核心优势。

• defer 延迟执行
• 资源释放与锁解锁
• RAII 式惯用法

• defer：在当前函数返回前执行注册的函数（LIFO，后进先出），用于延迟执行清理逻辑。
• 资源释放：f, err := os.Open(...); defer f.Close() —— 打开文件后立即 defer 关闭，函数任意路径返回时都自动关闭，避免资源泄漏。
• 锁解锁：mu.Lock(); defer mu.Unlock() —— 加锁后立即 defer 解锁，保证任何路径（含 panic）都解锁，避免死锁/锁泄漏。
• RAII 式惯用法：defer 类似 RAII——资源获取后立即注册释放，作用域（函数）结束时自动执行，与 Rust 的 Drop 类似。Go 用 defer 实现"资源获取后保证释放"的惯用法。
• 注意：defer 在函数返回时执行（不是作用域块），执行顺序 LIFO；defer 参数在注册时求值。
• 结论：defer 在资源/锁获取后立即注册释放，函数返回时自动执行，保证资源与锁的确定性释放，是 Go 的 RAII 式惯用法。

defer 延迟到函数返回执行（LIFO），在获取资源/锁后立即 defer 释放，保证任意路径释放，是 Go 的 RAII 式资源管理。

• CSP 模型
• goroutine + channel
• 通信而非共享

• CSP（Communicating Sequential Processes）：并发实体通过通信（channel）交互，而非共享内存。Go 的 goroutine + channel 是 CSP 的体现。
• goroutine：并发执行单元；channel：通信通道，goroutine 之间通过 channel 传递值（数据），实现"通过通信共享内存，而非通过共享内存通信"。
• 表达：goroutine 之间不直接共享变量（避免锁），而是通过 channel 发送/接收数据，数据在 channel 中流动，一次传递一个值，天然同步。channel 收发是 CSP 的通信原语。
• 好处：数据通过 channel 传递，避免共享可变状态与锁竞争；channel 的阻塞语义天然同步；并发结构清晰（生产者/消费者）。
• 注意：goroutine + channel 不是唯一方式，复杂共享状态仍可用 mutex（Go 两者都支持，视场景）。CSP 是 Go 的并发哲学。
• 结论：goroutine + channel 通过 channel 传递数据表达 CSP 并发，用通信代替共享内存，减少锁竞争与共享状态。

CSP 用 channel 通信而非共享内存。goroutine + channel 传递数据、避免共享可变状态，是 Go 并发哲学（通信代替共享）。

• 空接口 interface{} 与类型断言
• 泛型替代
• 反射的必要场景

• 空接口 interface{}：表示任意类型，用类型断言（v.(T)）或 type switch 恢复具体类型。缺点：丢失静态类型信息，运行时有类型转换开销与错误风险。
• 泛型替代：当"函数/类型对任意类型做相同操作"（如容器、map 函数、泛型工具）时，用泛型（func F[T any](x T)）替代空接口，保留静态类型、编译期检查、无运行时断言。泛型优于空接口（类型安全、性能）。
• 何时用泛型：操作对类型不敏感、可静态确定、需要类型安全（如泛型集合、排序、工具函数）。
• 何时必须反射：需要运行时类型信息（不知道类型、动态处理结构体字段、序列化/反序列化、标签遍历、ORM 映射、依赖注入）时，必须用反射（reflect），因为泛型在编译期已定型，无法处理"运行时才知道类型"的场景。反射开销大、安全性低，仅在没有静态方案时用。
• 结论：泛型能表达"对任意类型统一操作"时替代空接口（类型安全）；需要运行时动态类型信息（序列化、ORM、标签）时用反射。

泛型替代空接口做类型安全的统一操作；反射处理运行时动态类型（序列化、ORM、标签）。优先泛型，反射仅在没有静态方案时用。

• typestate 模式
• 类型状态机禁止非法序列
• 编译期 vs 运行时

• typestate（类型状态）模式：用类型编码对象的状态，每个状态是不同类型，方法只能在特定状态类型上调用，从而在编译期禁止非法操作序列。
• 实现：如 struct OpenFile / struct ClosedFile，read() 只在 OpenFile 上定义，close() 返回 ClosedFile。调用 read() 前必须先 open()（得到 OpenFile），对 ClosedFile 调用 read() 编译报错。类型状态机让"非法操作序列"无法编译。
• 编译期禁止：非法操作（如未打开就读、关闭后写）在编译期被拒绝，无需运行时检查，错误提前暴露。
• 与运行时校验对比：运行时校验（如 if !opened { return error }）在运行时检查，可能漏检、有开销；typestate 在编译期强制，类型系统保证合法序列，零运行时开销、更安全。但 typestate 只适合"状态有限、操作序列固定"的场景，复杂状态机可能用运行时校验。
• 结论：typestate 用类型编码状态，方法限定在特定状态类型，编译期禁止非法操作序列，比运行时校验更安全、零开销。

typestate 用类型编码状态，方法只在特定状态类型可用，编译期禁止非法序列。相比运行时校验，编译期保证、零开销，但适用状态有限场景。