解决Calendar库在Android与多平台项目中的重复类冲突问题

在使用kizitonwose/Calendar库时，开发者可能会遇到一个常见的构建错误：当同时引入Android专用模块和多平台模块时，会出现大量重复类冲突。这个问题源于库的设计架构，理解其背后的原理和解决方案对于正确使用该库至关重要。

问题本质分析

Calendar库提供了两种不同的Compose实现模块：

1. 专为Android设计的纯Android模块
2. 支持多平台(Android/iOS/Desktop/Wasm)的多平台模块

当开发者不慎在项目中同时引入这两个模块时，Gradle构建系统会检测到完全相同的类被两个不同的依赖提供，从而抛出"Duplicate class"错误。这是因为多平台模块已经包含了Android平台的所有实现，再额外引入Android专用模块就造成了重复。

解决方案

根据项目类型选择正确的依赖方式：

纯Android项目

仅需引入Android专用模块即可：

implementation "com.kizitonwose.calendar:compose:版本号"

多平台项目(KMP)

只需引入多平台模块，它会自动处理各平台的适配：

implementation "com.kizitonwose.calendar:compose-multiplatform:版本号"

多平台模块已经包含了Android实现，因此不需要额外引入Android专用模块。这种设计遵循了Kotlin多平台开发的"预期与实际"声明原则，其中多平台库会为每个目标平台提供适当的实现。

技术背景

这种模块划分方式体现了现代Kotlin多平台开发的典型模式：

1. 多平台库作为主入口点，声明对所有目标平台的支持
2. 平台专用库为不使用多平台的纯平台项目提供简化接入
3. 构建系统会根据项目类型自动选择正确的实现

理解这一点有助于开发者在使用其他多平台库时也能正确处理依赖关系，避免类似的冲突问题。

最佳实践建议

1. 明确项目类型：在添加依赖前确认是纯Android项目还是多平台项目
2. 统一依赖风格：团队内部应约定使用一致的依赖方式
3. 定期检查依赖：使用./gradlew dependencies检查是否存在不必要的重复依赖
4. 理解多平台架构：深入学习Kotlin多平台的工作原理可以避免许多类似问题

通过遵循这些原则，开发者可以充分利用Calendar库的强大功能，同时避免构建时的类冲突问题。