linux xattr 在 c# 中不可直接访问，需通过 p/invoke 调用 libc 的 getxattr/setxattr 等函数，或使用 unixbase、libuv 等封装库；注意路径、编码、缓冲区大小及权限限制。
Linux xattr 在 C# 中不可直接访问
Windows 和 .NET 运行时默认不提供对 Linux 扩展属性（xattr）的跨平台 API 支持。File、FileInfo 等类完全忽略 xattr；System.IO 下没有任何公开接口能读写 user.mykey 或 security.selinux 这类属性。
必须调用 libc 的 syscall 或封装库
本质是绕过 .NET 抽象层，直接调用 getxattr、setxattr、listxattr 这些 libc 函数。C# 里只能靠 P/Invoke 实现，且需注意：
-
libc路径在不同发行版可能不同：/usr/lib/libc.so.6（Debian/Ubuntu）、/usr/lib64/libc.so.6（CentOS/RHEL）——硬编码路径会失败 - 函数签名必须严格匹配：比如
size_t在 64 位系统是ulong，不是int；name参数是 null-terminated UTF-8 字节数组，不能直接传string - 缓冲区大小需两次调用：先传
null获取所需长度，再分配对应字节数组重试——否则易触发ERANGE
示例关键片段：
[DllImport("libc.so.6", SetLastError = true)]
private static extern int getxattr(string path, string name, byte[] value, ulong size);推荐用 UnixBase 或 libuv 封装层
自己手写 P/Invoke 容易踩内存越界、编码转换、错误码映射等坑。更稳妥的做法是复用已有封装：
-
UnixBase（NuGet 包）提供了UnixFileSystem.GetExtendedAttribute等方法，底层已处理 libc 路径探测和 UTF-8 转换 -
libuv（通过Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv间接可用）也暴露了 xattr 接口，但需自行提取头文件绑定 - 避免用
Process.Start("getfattr")：启动子进程开销大、输出解析脆弱、无法原子操作、权限受限时直接失败
ext4 上 xattr 的实际限制必须检查
即使调用成功，也不代表一定能存任意数据：
- 单个 xattr 值最大约 64 KiB（取决于 ext4 inode 大小和是否启用
inline_data）；超限返回ERANGE -
user.命名空间默认开启，但若挂载时加了nouser_xattr，所有user.*操作都会报EOPNOTSUPP -
security.*和trusted.*需要 root 权限或特定 capability（如CAP_SYS_ADMIN），普通用户进程必然失败 - 容器环境（如 Docker）中，宿主机挂载选项和容器运行时安全策略可能进一步屏蔽 xattr 支持
真正上线前，得用 getfattr -d /path/to/file 和 mount | grep xattr 实地验证目标环境是否就绪。
