在SBT shell中执行子项目任务前，为何要先将该子项目设为活跃状态？

• 核心结论：SBT 1.x及以上的现代版本中，两种调用方式本身不存在功能层面的差异，“切换项目再执行任务更安全”的说法源于0.13及更早版本的历史经验，并非无意义的盲从惯例。
• 差异来源1：旧版本SBT的作用域解析bug

SBT 0.13之前的版本作用域推断逻辑存在缺陷，使用模块名/任务名的前缀调用时，只会显式指定项目轴，剩余的配置轴、任务轴会继承当前会话的上下文状态，部分场景下会出现作用域解析错误，最终执行的不是预期的任务。而使用project 模块名切换子项目时，会重置当前会话的所有作用域状态为该子项目的默认值，不会受之前的操作影响，因此被认为更可靠。

• 差异来源2：多配置场景下的行为确定性

就算是现代SBT版本，也存在上下文作用域继承的正常逻辑：如果你之前执行过Test/console这类指定了配置轴的命令，当前会话的默认配置轴会停留在Test层级，此时直接执行module1/someTask会被解析为module1/Test/someTask，和切换到module1后执行的默认绑定Compile配置的someTask行为完全不同。切换项目的操作会重置默认配置轴为子项目的默认值，不会出现这类非预期的上下文污染，对于不熟悉SBT作用域规则的开发者来说确实更不容易出错。

• 差异来源3：多任务执行的容错性

如果你需要在同一个子项目下连续执行多个任务，切换项目的写法project module1 ; compile ; test ; package不需要重复指定子项目前缀，相比前缀写法module1/compile ; module1/test ; module1/package更简洁，也不会出现漏写前缀导致任务跑到其他项目的问题，长期使用下来容错性更高。

• 现代版本的使用建议

如果你明确了解当前会话的作用域状态，或者显式指定全作用域（比如module1/Compile/someTask），直接使用前缀调用完全没有问题，不需要刻意先切换子项目。只有当你不确定之前的操作修改了哪些会话作用域时，切换子项目的方式能保证行为符合预期。

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