背景：壳工程中引入了自己维护的A组件和B组件，A组件和B组件同时引入了三方的C组件，如何保证A组件和B组件使用相同的版本的C组件？
方案一
- 在壳工程中锁定 C 组件版本
在壳工程的 pubspec.yaml 中手动添加 C 组件的依赖，并明确指定其版本号。这样，A 组件和 B 组件将继承这个依赖，并确保使用的是相同版本的 C 组件。示例：
dependencies:
C_component: ^1.2.3
- 移除 A 和 B 组件中对 C 组件的显式依赖
确保 A 和 B 组件的 pubspec.yaml 中没有显式依赖 C 组件。这样它们将通过壳工程继承依赖。
方案二
使用 dependency_overrides
如果 A 组件和 B 组件中已经显式声明了 C 组件，但它们使用的版本不同，且你无法直接修改它们的 pubspec.yaml，你可以在壳工程的 pubspec.yaml 中使用 dependency_overrides 强制指定 C 组件的版本号：
dependency_overrides:
C_component: ^1.2.3
最终：使用 flutter pub deps 检查依赖关系
运行 flutter pub deps 可以查看整个项目的依赖关系树，确认 A 和 B 组件是否使用了相同版本的 C 组件。
通过这些方法，可以确保 A 和 B 组件使用相同的 C 组件版本，并避免由于不同版本引发的潜在冲突问题。
以上方案会导致A组件和B组件无法独立运行：
当你在壳工程中统一管理 C 组件的依赖，并移除了 A 组件和 B 组件对 C 组件的显式依赖后，A 和 B 组件可能会失去独立性，无法在壳工程外单独运行。这是因为在组件化方案中，A 和 B 组件的 pubspec.yaml 文件中不再声明 C 组件的依赖，导致它们在单独运行时缺少必需的依赖项。
要解决这个问题，同时确保 A 和 B 组件既能在壳工程中复用相同版本的 C 组件，又能在独立开发或运行时保持完整性，可以考虑以下几种解决方案：
方案一
使用 dev_dependencies
如果 A 和 B 组件在独立运行时需要 C 组件，但在壳工程中你希望由壳来统一管理它的依赖，那么可以将 C 组件添加到 A 和 B 的 dev_dependencies 中，而不是 dependencies。这样，在独立运行时会安装 C 组件的依赖，但在壳工程中运行时，由壳工程来管理依赖版本。
dev_dependencies:
C_component: ^1.2.3
优点：A 和 B 组件仍能独立运行，且壳工程内可以统一管理版本。
缺点：这种方式适用于 C 组件仅用于开发、测试等非生产环境的情况。如果 C 组件在生产环境也需要使用，这可能不是理想选择。
方案二
保留 A 和 B 的 dependencies 并使用 dependency_overrides
你可以在 A 和 B 组件中保留对 C 组件的显式依赖，同时在壳工程中使用 dependency_overrides 来强制指定 C 组件的版本号。这种方式可以确保 A 和 B 在独立运行时依赖正常，同时在壳工程中强制使用相同版本的 C 组件。
壳工程的 pubspec.yaml 文件：
dependency_overrides:
C_component: ^1.2.3
A 组件的 pubspec.yaml 文件：
dependencies:
C_component: ^1.2.0 # 版本号可以不同
B 组件的 pubspec.yaml 文件：
dependencies:
C_component: ^1.3.0 # 版本号可以不同
优点：A 和 B 组件可以独立运行，并且在壳工程内可以强制保持相同的 C 组件版本。
缺点：在开发过程中可能会产生冗余的依赖声明。
方案三
使用本地依赖或者 Git 仓库进行管理
你可以将 C 组件作为一个 Git 仓库或者本地包进行管理，统一在 A 组件、B 组件和壳工程中引用同一个 C 组件的代码库。
A 和 B 组件以及壳工程的 pubspec.yaml 文件可以通过如下方式统一引用 C 组件：
dependencies:
C_component:
git:
url: git://path_to_c_component_repo.git
ref: ^1.2.3
或者如果你有一个本地的 C 组件路径：
dependencies:
C_component:
path: ../path_to_c_component
优点：A 和 B 可以独立运行，且依赖代码库的版本完全一致。
缺点：需要确保 C 组件代码库的路径或 Git 地址在所有环境中都可访问。
通过这些方法，可以平衡组件化架构中的依赖管理，同时保持组件的独立性。
