如何优雅处理.NET6跨平台应用的Windows/Linux系统特定操作？

你当前的封装方案只是将分支逻辑集中到了类内部，并没有真正消除分支判断。如果想要彻底优化代码结构、提升扩展性，这里提供两种更优的实现思路：

方案一：策略模式 + 依赖注入（推荐用于复杂场景） #

通过定义抽象接口，为不同平台实现对应的策略类，再通过依赖注入在运行时自动匹配平台实现，完全消除业务代码中的分支判断。

步骤1：定义抽象接口 #

public interface IDefaultFolderProvider
{
    string GetDefaultFolderPath();
}

步骤2：实现各平台策略类 #

// Linux平台实现
public class LinuxDefaultFolderProvider : IDefaultFolderProvider
{
    public string GetDefaultFolderPath()
    {
        return Environment.GetFolderPath(Environment.SpecialFolder.UserProfile);
    }
}

// Windows平台实现
public class WindowsDefaultFolderProvider : IDefaultFolderProvider
{
    public string GetDefaultFolderPath()
    {
        return Environment.GetFolderPath(Environment.SpecialFolder.Desktop);
    }
}

步骤3：注册平台特定服务 #

在Program.cs中根据当前平台注册对应的实现：

builder.Services.AddSingleton<IDefaultFolderProvider>(sp =>
{
    if (OperatingSystem.IsLinux())
    {
        return new LinuxDefaultFolderProvider();
    }
    else if (OperatingSystem.IsWindows())
    {
        return new WindowsDefaultFolderProvider();
    }
    throw new PlatformNotSupportedException("当前平台未实现默认文件夹路径获取逻辑");
});

步骤4：业务代码中使用 #

通过构造函数注入接口，直接调用方法即可：

public class YourBusinessService
{
    private readonly IDefaultFolderProvider _folderProvider;

    public YourBusinessService(IDefaultFolderProvider folderProvider)
    {
        _folderProvider = folderProvider;
    }

    public void DoSomething()
    {
        string path = _folderProvider.GetDefaultFolderPath();
        // 后续业务逻辑
    }
}

优点：扩展性极强，新增平台只需添加对应策略类并修改注册逻辑；符合依赖倒置原则，业务代码与平台逻辑解耦；便于单元测试（可Mock接口）。

方案二：平台特定编译指令（适合简单场景） #

利用.NET的编译指令，在编译阶段就为不同平台生成对应的代码，运行时无分支判断，性能略优。

public static class DefaultFolderHelper
{
    public static string GetDefaultFolderPath()
    {
#if LINUX
        return Environment.GetFolderPath(Environment.SpecialFolder.UserProfile);
#elif WINDOWS
        return Environment.GetFolderPath(Environment.SpecialFolder.Desktop);
#else
        throw new PlatformNotSupportedException();
#endif
    }
}

调用方式：

string path = DefaultFolderHelper.GetDefaultFolderPath();

优点：实现简单，运行时无分支开销；缺点：扩展性差，新增平台需要修改现有类；无法在同一编译产物中支持多平台（需单独编译各平台版本）。

方案选择建议 #

• 如果你的跨平台逻辑后续可能扩展（比如新增macOS支持），或者平台特定操作复杂，优先选择策略模式+依赖注入。
• 如果只是简单的单一场景，且不需要频繁扩展平台，可以使用编译指令方案。

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