Kotlin Multiplatform库发布方案咨询：Fat-AAR vs 多模块发布

方案1：优化逐个模块发布流程（优先推荐） #

你当前觉得逐个发布模块繁琐，核心痛点是重复的手动操作，完全可以通过Gradle配置彻底解决：

• 统一配置发布参数：在项目根目录的build.gradle.kts中，用subprojects块批量给所有模块应用maven-publish插件，统一配置仓库地址、版本号、开发者信息等通用内容，避免每个模块重复编写相同配置。
• 一键发布全量模块：执行Gradle命令 ./gradlew publishAllPublicationsToMavenLocal（本地发布）或对应远程仓库的发布任务，一次命令即可完成所有模块的发布，无需逐个操作。
• 可选：通过Gradle的发布过滤规则，标记仅对外暴露FeatureX及其依赖的必要模块，避免发布纯内部使用的模块（如果有的话）。

这种方式保留了模块化设计的优势，依赖管理清晰可控，不会出现Fat-AAR的依赖冲突问题，同时彻底解决了发布复杂度高的痛点。

方案2：用聚合模块替代Fat-AAR #

如果希望消费方仅需引入一个依赖，可创建一个聚合模块（例如命名为FeatureXBundle）：
这个模块不包含任何业务代码，仅在build.gradle.kts中声明对FeatureX的依赖，然后发布该聚合模块。

消费方引入这个聚合模块后，Gradle会自动拉取所有传递依赖（包括FeatureX、Core、Common、Network），既实现了"单依赖引入"的需求，又无需手动打包Fat-AAR，依赖冲突由构建工具自动处理，可靠性更高。

不推荐继续使用Fat-AAR的原因 #

Kotlin Multiplatform项目涉及多平台目标（JVM、iOS、JS等），Fat-AAR的打包逻辑在多场景下会异常复杂，既要处理JVM端依赖，还要兼顾其他平台产物，极易出现依赖重复、平台适配错误等问题，后续维护成本远高于模块化发布或聚合模块方案。

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