C#没有“Data Weaving”机制，实际需求是异构数据整合；应使用System.Text.Json、CsvHelper等流式解析工具，定义统一领域模型并显式映射字段，手动处理缺失、类型冲突与重复主键。
直接说结论：C# 本身没有叫“Data Weaving”的内置机制，这不是 .NET 的标准术语；你实际想做的，是把多个结构不同、格式不同（比如 JSON + CSV + XML）、甚至来源不同（本地文件 + API 响应）的文件数据，按业务逻辑拼成一个统一对象视图——这属于数据整合（data integration），不是编织。
为什么搜 Data Weaving 会踩坑
这个词在 C# / .NET 生态里几乎没人用，它常见于 Java 领域（如 AspectJ 的编译期织入），或某些特定 ETL 工具的宣传文案。用它搜文档、NuGet 包或 Stack Overflow，大概率找不到你要的东西，反而浪费时间。
你真正该关注的是：如何建模异构源 → 如何解析各格式 → 如何对齐字段 → 如何合并去重或补全。
- 常见错误现象：
System.InvalidOperationException: Sequence contains no elements，常因某文件为空或字段名不一致却硬用First()导致 - 别指望一个类库自动“理解语义”——CSV 里的
"active"和 JSON 里的"is_enabled": true不会自己映射，得你写规则 - 如果文件量大（>10MB 或 >1000 行），别用
File.ReadAllText全读进内存，优先选流式解析（JsonSerializer.DeserializeAsync、CsvReader）
System.Text.Json + CsvHelper + 自定义映射类怎么搭起来
这是最轻量、可控性最强的组合：JSON 用原生 System.Text.Json，CSV 用成熟的 CsvHelper，XML 可用 XmlSerializer 或 XDocument，再统一转成你的中间模型。
关键不是工具，而是中间层设计：
- 定义一个干净的领域类（比如
UserProfile），只含业务需要的字段，不含任何源格式细节 - 为每种源写独立的解析器，返回
IEnumerable<userprofile></userprofile>，而不是原始JObject或CsvRecord - 字段映射必须显式声明：CSV 的
"usr_id"→UserProfile.Id，JSON 的"userId"→UserProfile.Id，不能靠命名猜测 - 示例片段（CSV 解析）：
var reader = new StreamReader("users.csv"); var csv = new CsvReader(reader, CultureInfo.InvariantCulture); var users = csv.GetRecords<CsvUserRow>() .Select(x => new UserProfile { Id = x.usr_id, Name = x.full_name });
合并时怎么处理字段缺失、类型冲突、重复主键
这才是真实痛点。三个文件都含用户信息，但 A 缺邮箱、B 的年龄是字符串、C 有两条相同 ID 的记录——不处理，合出来就是脏数据。
- 缺失字段：用
??或默认值填充，但要记录哪些字段来自哪个源（加个SourceOrigin字段），方便后续审计 - 类型冲突：比如年龄字段，CSV 是
"25"，JSON 是25，XML 是<age>twenty-five</age>—— 必须在各自解析器里做转换，不要留到合并阶段 - 重复主键：用
GroupBy(x => x.Id)后，明确策略——取最新时间戳的？取字段最全的？还是抛异常人工介入？别用Distinct()简单去重 - 性能注意：合并前先
.ToList()或.ToArray()把各源数据落地，避免多次枚举导致重复解析（尤其 XML 或远程响应）
真正麻烦的从来不是语法怎么写，而是字段语义对不齐、空值含义不一致、时间格式五花八门——这些没法靠库自动解决，得一行行看样本数据，写 case-by-case 的转换逻辑。
