Flutter Rust Bridge中的模块可见性与代码生成控制

在Flutter Rust Bridge项目中，开发者经常需要处理Rust模块间的可见性问题，同时控制哪些代码需要生成对应的Dart绑定。本文将深入探讨这一常见场景的解决方案。

Rust模块可见性基础

Rust提供了精细的模块可见性控制机制，主要包括以下几种：

• pub: 完全公开，任何外部代码都可以访问
• pub(crate): 仅在当前crate内可见
• pub(super): 仅在父模块中可见
• 无修饰符: 仅在当前模块内可见

典型项目结构问题

在典型的Flutter+Rust跨平台应用中，开发者通常会采用类似如下的项目结构：

api/
  screens/
    home/
      home_logic.rs
      home_state.rs
    settings/
      settings_logic.rs
      settings_state.rs

其中state.rs文件包含状态管理相关代码，logic.rs包含业务逻辑实现。这种分离有助于保持代码的清晰和组织性。

常见痛点

开发者经常遇到的问题是：

1. logic.rs需要访问state.rs中的类型和函数
2. 但又不希望这些类型和函数暴露给Dart端
3. 如果使用pub修饰，Flutter Rust Bridge会默认生成对应的Dart绑定

解决方案：使用pub(crate)

正确的做法是使用Rust的pub(crate)可见性修饰符。这种修饰符：

1. 允许同一crate内的其他模块访问
2. 阻止外部crate（包括Dart绑定生成器）看到这些定义
3. 无需额外添加#[frb(ignore)]注解

例如：

// home_state.rs
pub(crate) struct HomeState {
    pub(crate) counter: i32,
}

impl HomeState {
    pub(crate) fn new() -> Self {
        Self { counter: 0 }
    }
}

设计哲学理解

Flutter Rust Bridge的设计哲学是：

• 只有真正需要跨语言边界共享的类型和函数才应该标记为pub
• crate内部的实现细节应该使用更严格的可见性控制
• 这种设计鼓励开发者思考API边界，产生更清晰的架构

最佳实践建议

1. 默认使用最严格的可见性（无修饰符）
2. 需要跨文件共享时使用pub(crate)
3. 只有确实需要暴露给Dart端的才使用pub
4. 对于复杂项目，考虑使用pub(super)进一步限制可见范围

通过合理运用Rust的可见性系统，开发者可以既保持代码的组织性，又避免不必要的Dart绑定生成，提高编译效率和代码质量。