首选 WebHDFS 因 libhdfs 需 P/Invoke、跨平台兼容性差且 .NET 5+ 默认不支持；Ceph 优选 S3 接口（AWS SDK）而非 Rados.NET，因后者依赖原生库且新版 .NET 支持弱；统一抽象应聚焦 IObjectStorage 接口的存取删列四动作及错误重试策略，而非强行语义对齐。
用 C# 连 HDFS 为什么首选 WebHDFS 而不是 libhdfs？
因为官方 libhdfs 是 C 接口，.NET 调用需 P/Invoke，跨平台（尤其是 Linux/macOS）兼容性差、调试困难，且 .NET Core/.NET 5+ 默认不支持直接加载旧版 libhdfs.so。实际项目中，90% 以上的 C# HDFS 客户端都走 REST —— 即启用 WebHDFS 后，用 HttpClient 调用 /webhdfs/v1/ 端点。
关键前提：确保 Hadoop 集群已开启 WebHDFS（hdfs-site.xml 中 dfs.webhdfs.enabled = true），并确认 Namenode 的 HTTP 端口（默认 9870）可被客户端访问。
- 认证方式优先选
Simple（测试）或Kerberos（生产），避免用Delegation Token做长期会话——Token 有生命周期且需手动刷新 - 路径必须 URL 编码，例如
/user/test/中文.txt要转成/user/test/%E4%B8%AD%E6%96%87.txt，否则 400 错误 - 大文件上传不要用单次 PUT，改用
CREATE→ 重定向到 DataNode →PUT到该地址，否则可能触发 Namenode 内存溢出
Ceph 的 C# 客户端该选 Rados.NET 还是 S3 兼容接口？
取决于你用的是 Ceph 的哪一层：如果直连底层对象存储（RADOS），用 Rados.NET；如果 Ceph 已启用 radosgw（即 S3 兼容网关），则直接用 AWS SDK for .NET 的 AmazonS3Client 更稳。
Rados.NET 是对 librados 的封装，需在运行环境安装对应平台的 librados.so（Linux）或 rados.dll（Windows），且仅支持 .NET Framework / .NET Core 3.1（新版 .NET 6+ 需自行编译绑定）。而 AmazonS3Client 完全托管，支持所有现代 .NET 版本，自动处理重试、分块上传、签名 v4。
- 用 S3 方式时，Endpoint 填
http://your-ceph-gateway:8000，不是 Ceph monitor 地址 - AccessKey/SecretKey 来自
radosgw-admin user create输出，不是 Cephx 密钥 - 桶名（bucket）必须全局唯一且符合 DNS 规则（小写字母、数字、短横线），否则
AmazonS3Exception报错 “InvalidBucketName”
如何统一抽象 HDFS 和 Ceph 的文件操作？
别强行写一个“通用 FileSystem” 接口去覆盖所有行为——HDFS 没有真正的“删除后回收站”开关控制，Ceph S3 没有原子 rename，语义差异太大，硬抽象只会埋坑。更务实的做法是：按业务动作分层封装。
例如，定义一个 IObjectStorage 接口只管「存、取、删、列」四个动作，内部由具体实现类（WebHdfsClient / S3ObjectClient）各自处理协议细节。重点统一的是错误处理策略和重试逻辑，而不是 API 形态。
- HDFS 的
GETFILESTATUS返回 404 表示路径不存在，Ceph S3 的HeadObjectAsync返回AmazonS3Exception且StatusCode == HttpStatusCode.NotFound才等价 - 列出文件时，HDFS 用
?op=LISTSTATUS一次最多返回 1000 项，需翻页；Ceph S3 用ListObjectsV2Async支持ContinuationToken，但默认只返回 1000 - 不要依赖
Exists()方法做条件判断——它本质是 HEAD 请求，高并发下易成性能瓶颈，应尽量合并到主操作中（如上传前不预检查，失败后捕获特定异常再处理）
生产环境必须检查的三个配置点
很多“连不上”的问题其实和代码无关，而是环境配置漏项。
- HDFS：确认客户端机器的
/etc/hosts里有 Namenode 主机名映射，否则 Kerberos 认证时krb5.conf中的 realm 解析失败，报错GSSException: Defective token - Ceph S3：
radosgw默认禁用跨域（CORS），前端直传会卡在预检请求（OPTIONS），需用radosgw-admin cors set显式配置允许的 Origin 和 Headers - .NET 运行时：Linux 上跑
Rados.NET时，若提示Unable to load shared library 'rados'，不是缺库，而是缺依赖——执行ldd librados.so会发现缺libboost_system或libcurl-gnutls，得补全系统包
分布式文件系统的客户端从来不是“配好连接串就能用”，协议层、认证层、网络层、运行时层，任何一层的隐含约束没满足，都会在某个看似随机的时刻崩给你看。
