应先用 File.GetAttributes 获取当前属性，再用按位与操作清除只读位：File.SetAttributes(path, attrs & ~FileAttributes.ReadOnly)，避免误清隐藏、系统等其他属性。
怎么用 File.SetAttributes 去掉只读标记
文件被设为只读后，File.WriteAllText 或 File.Move 会直接抛出 UnauthorizedAccessException。核心解法就是先调用 File.SetAttributes 清掉 FileAttributes.ReadOnly 标志。
实操建议：
- 必须先读取当前属性，再按位清除只读位：
var attrs = File.GetAttributes(path); File.SetAttributes(path, attrs & ~FileAttributes.ReadOnly);—— 直接传FileAttributes.Normal会意外清掉隐藏、系统等其他属性 - 路径必须存在，否则抛
FileNotFoundException；权限不足时抛UnauthorizedAccessException，需提前捕获 - 对符号链接（symlink）操作时，.NET 6+ 默认作用于目标文件；若要修改链接本身属性，得用
File.SetAttributes配合FileOptions.OpenReparsePoint（需 P/Invoke）
FileAttributes 里还有哪些常用标志会影响写入
只读只是表象，真正卡住写入的可能是组合属性。比如某文件同时带 ReadOnly 和 Hidden，只清只读还不够——但更常见的是误判：隐藏属性本身不阻止写入，而系统属性在某些 NTFS 策略下可能触发额外校验。
关键点：
-
FileAttributes.System：Windows 下部分系统文件（如pagefile.sys）即使去掉只读也无法写入，这是内核级保护，代码无解 -
FileAttributes.Directory：不能对目录用File.SetAttributes，得用Directory.SetAttributes - NTFS 权限（ACL）和文件属性是两层机制：清掉只读属性后仍可能因 ACL 拒绝写入，此时异常仍是
UnauthorizedAccessException，但原因不同
为什么 Process.Start("attrib", "-R path") 不推荐
调用外部命令看似简单，但实际埋了三个坑：跨平台失效、路径空格转义错误、权限上下文不一致。
具体问题：
- Linux/macOS 没
attrib命令，chmod又不对应 Windows 的只读语义（它改的是执行权限） - 路径含空格时，
Process.Start参数传递容易漏引号，导致命令截断 - 如果程序以普通用户运行，但文件属管理员所有，
attrib可能静默失败（返回码 0 但没生效），而File.SetAttributes会明确抛异常
异步场景下修改属性要注意什么
.NET 6+ 提供了 File.SetAttributesAsync，但它只是同步方法的包装器（即线程池调度，非真正异步 I/O）。所以高并发批量处理文件时，并不会提升吞吐量，反而增加线程调度开销。
更现实的考量：
- 不要在
async方法里混用同步的File.SetAttributes，容易引发死锁（尤其 UI 线程上下文） - 如果真要优化性能，优先考虑批量检查 + 单次属性修改，而不是为每个文件单独调用
- UWP 或 .NET MAUI 等沙盒环境里，
File.SetAttributes可能受限于应用能力声明（Capabilities），需确认uap:Capability是否包含filesBroadFileSystemAccess
文件属性和 ACL 权限是两套独立机制，只改属性解决不了权限问题；而 NTFS 系统属性这类内核级限制，代码层面根本绕不过去。
