为什么Kotlin允许包结构与项目文件夹结构不匹配？

Kotlin中允许package声明的包结构与实际项目文件夹结构不匹配，是官方在设计阶段就明确做出的灵活性决策，核心动因和适用场景如下：

核心设计动因 #

• 适配多平台语言定位：Kotlin从诞生之初就定位于支持JVM、JS、Native等多端编译的全栈语言，跨平台项目中不同平台的源码需要放在独立的源码集目录（如commonMain、jvmMain、jsMain）下，如果强制包名与目录绑定，同属一个业务逻辑的跨平台代码就需要在每个源码集下都复刻完全相同的目录层级，会产生大量冗余结构，提升跨平台开发成本
• 降低轻量场景的使用门槛：不同于Java主要服务于中大型工程的设计思路，Kotlin同时支持单文件脚本、小型工具类项目的开发场景，如果强制要求包名对应目录，开发者写一个几十行的.kts脚本也需要先创建多层嵌套目录，明显不符合轻量场景的使用需求
• 兼容灵活的项目重构需求：官方不希望用目录结构限制开发者的包名设计，避免重构包名时必须批量移动文件带来的额外成本，同时JetBrains作为IDE厂商，自身的开发工具完全可以支持包名与目录不匹配场景下的代码索引、跳转等能力，不需要靠强制绑定的规则来降低工具实现成本

支持的典型使用场景 #

• 多平台Kotlin项目开发：跨平台项目中可以把不同平台的实现代码放在对应平台的源码集目录下，统一声明相同的包名，完美适配expect/actual关键字的跨平台逻辑匹配规则，不需要在每个源码集下都创建冗余的目录层级
• 轻量脚本与单文件工具开发：编写小型Kotlin脚本、单文件工具类时，直接在文件顶部声明package xxx.xxx.xxx即可对外暴露符合规范的包名，不需要额外创建对应的文件夹结构，大幅简化轻量场景的开发流程
• 大型项目渐进式重构：对已有项目做包名调整、架构重构时，可以先修改文件顶部的包声明，不需要一次性移动所有相关文件的目录位置，后续再逐步调整目录结构，降低重构过程中出现编译错误的风险，也方便拆分重构的步骤
• 自定义源码组织规则：部分项目会选择按业务功能、模块类型划分目录，而非按包名层级划分目录，比如把所有支付相关的代码统一放在/pay目录下，所有用户相关代码放在/user目录下，包结构与目录不匹配的规则可以完美支持这类自定义的源码组织需求
• 多语言混合开发项目兼容：在同时存在Java、Kotlin、甚至其他JVM语言的项目中，部分语言的目录组织规则与Kotlin不同，不强制绑定包名与目录的规则可以让Kotlin适配这类项目的既有目录结构，不需要为了适配Kotlin修改全项目的目录布局

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