Flutter多桌面平台开发：如何排除非目标平台特定依赖？

你的方案完全可行，是实现平台专属依赖隔离+核心逻辑共享的合理路径，能直接解决你提到的「构建时剔除不必要依赖」的问题——每个平台项目的pubspec.yaml只引入自身需要的主题/图标库，构建过程自然不会打包其他平台的依赖。

关于官方文档要点的补充 #

官方在代码拆分的指导中，确实推荐用共享package承载跨平台核心逻辑，你的my_app_shared思路完全契合这个方向。但官方还提到了另一种轻量方案：单项目内的条件依赖/条件导入，比如在根项目的pubspec.yaml中用platforms字段指定依赖生效的平台：

dependencies:
  fluent_ui:
    version: ^4.0.0
    platforms:
      windows: {}
  adwaita:
    version: ^1.0.0
    platforms:
      linux: {}

不过这种方式适合需要单项目多平台构建的场景，而你的多项目分离方案优势更明显：各平台可以完全独立定制UI结构、原生集成逻辑，甚至可以针对不同平台发布不同版本，灵活性更高。

实用建议 #

• 简化shared包结构：你提到可以用根目录的/lib作为shared代码，其实没必要单独创建my_app_shared目录。直接在根项目中存放ViewModel、共享组件、业务逻辑，然后让各平台项目通过路径依赖根项目即可，比如在my_app_windows/pubspec.yaml中添加：

  dependencies:
    my_app_core:
      path: ../
  

  这样只需要维护一份核心代码的pubspec.yaml，减少重复配置。
• 抽象平台UI接口：在核心包中定义抽象的主题、图标组件接口（比如PlatformThemeData、PlatformIcon），各平台项目实现这些接口后，核心逻辑可以直接调用抽象层，不用关心具体平台的UI实现，进一步强化MVVM的解耦。
• 独立构建与测试：每个平台项目单独执行构建命令（比如flutter build windows），测试时也可以针对各平台单独跑UI测试，避免跨平台环境干扰。核心逻辑的单元测试放在根项目中，保证跨平台一致性。
• 原生交互的隔离：如果需要调用平台原生API（比如Windows的系统弹窗、Mac的菜单栏），不要在核心包中写具体实现，而是在核心包定义抽象方法，各平台项目中编写对应的原生集成代码，或者封装成小型plugin供平台项目依赖。

内容的提问来源于stack exchange，提问作者Otacon