C#中UNC路径访问需规避默认保守策略：规范路径格式、配置权限、用NetworkConnection映射盘符、异步时保持Windows身份上下文，跨平台需改用SMB库或HTTP API。
UNC路径在C#中直接使用File类会报错
直接用 File.Exists(@"\servershare est.txt") 或 Directory.GetFiles(@"\servershare") 很可能抛出 System.UnauthorizedAccessException 或 System.IO.IOException，不是权限问题，而是.NET默认对UNC路径的访问策略较保守，尤其在非交互式上下文（如Windows服务、IIS应用池）中更明显。
关键原因：.NET Framework 4.0+ 默认启用 useLegacyUNCPathHandling 的兼容模式，且部分API（如 DirectoryInfo 构造）在路径末尾有反斜杠时会提前解析失败。
- 确保UNC路径格式规范：以双反斜杠开头，不以反斜杠结尾（
@"\servershare"✅，@"\servershare"❌） - 避免在路径中混用正斜杠或未转义的单反斜杠
- 若调用方是IIS站点，确认应用池标识（ApplicationPoolIdentity）已获共享服务器上的NTFS + 共享级权限
用NetworkConnection辅助类挂载临时映射盘符更可靠
当需要频繁读写、或调用依赖驱动器字母的API（如某些第三方库、旧版Process.Start启动命令行工具）时，手动映射为 Z: 这类盘符反而更稳。这不是“绕开UNC”，而是利用Windows原生SMB会话管理机制。
核心是调用 WNetAddConnection2 Win32 API，封装成 NetworkConnection 类后可复用：
using (var conn = new NetworkConnection(@"Z:", @"\servershare", "domainuser", "password"))
{
File.Copy(@"Z:data.txt", @"C:local.txt");
}
- 映射成功后，所有标准
File/Directory操作都可用，无需改写逻辑 - 务必用
using确保WNetCancelConnection2被调用，否则盘符残留会导致后续挂载失败 - 密码明文传入有风险；生产环境建议用
CredentialCache.DefaultNetworkCredentials复用当前登录凭据
异步访问UNC需特别注意上下文捕获
File.ReadAllBytesAsync 或 Directory.EnumerateFiles 在ASP.NET Core后台任务中调用 UNC 路径，容易因线程切换丢失Windows身份令牌，导致401错误。
解决方案不是禁用异步，而是显式控制执行上下文：
- 在
WebHostBuilder配置中启用UseWindowsService()（若部署为服务），并确保服务账户有网络访问权 - 避免在
async void方法中访问UNC；统一用async Task并 await 到底 - 必要时用
Task.Run(() => File.ReadAllBytes(path)).Result强制同步执行（仅限IO密集且短时场景，勿滥用）
跨平台.NET 6+需改用SMB库替代原生UNC
.NET 6+ 的 System.IO 在Linux/macOS上完全不支持UNC路径——@"\servershare" 会被当作非法路径直接抛 ArgumentException。
此时必须切换技术栈：
- 用
SMBLibrary（NuGet包）实现纯托管SMB客户端，支持连接、列表、读取，但不支持写入大文件 - 调用系统命令：Linux下用
mount -t cifs挂载到本地目录，再用标准IO操作挂载点（需root权限） - 改用HTTP/REST API替代文件共享，由共享服务器提供文件服务接口
没有银弹。Windows服务继续用原生UNC，跨平台部署就得接受协议层重构——这点常被忽略，直到CI构建失败才暴露。
