为何部分开发者需使用FileSystem.Current.OpenAppPackageFileAsync？

从给出的IFileSystem接口和FileSystem静态类定义来看，开发者选择FileSystem.Current.OpenAppPackageFileAsync（版本A）而非直接调用静态方法（版本B），主要有以下几个原因：

• 提升代码可测试性
  FileSystem.Current是IFileSystem接口的实例，接口天生适合做Mock。在单元测试中，开发者可以轻松替换Current为模拟的IFileSystem实现，比如返回预设的数据流，完全不需要依赖真实文件系统。而版本B的静态方法由于静态成员行为难以拦截或替换，会导致单元测试必须依赖实际文件操作，测试效率和可靠性都受影响。

• 支持自定义文件系统行为
  如果业务需要扩展或替换默认文件系统逻辑（比如添加操作日志、适配特定平台、用内存文件系统做缓存），开发者只需实现IFileSystem接口，再替换FileSystem.Current的实例即可。版本B的静态方法绑定死了默认实现，无法灵活替换底层逻辑，除非修改静态类内部代码，不符合开闭原则。

• 遵循接口导向的编程规范
  很多团队遵循依赖倒置原则（SOLID原则之一），优先依赖抽象（IFileSystem接口）而非具体实现（静态FileSystem类）。版本A直接使用Current这个接口实例，让代码更贴合这类规范，模块间依赖关系更清晰，便于后续维护和扩展。

• 确保使用已配置的实例
  在复杂初始化场景中，FileSystem.Current可能已经被提前配置了自定义实现（比如在依赖注入容器中注册后赋值）。直接调用Current的方法能确保使用的是符合业务需求的初始化实例，而静态方法默认使用基础实现，无法感知这种自定义配置。

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