文本解析驱动

1业务变更的“爆炸半径”太大（严重违反开闭原则）
---

假设业务要求在中间多加一列 AGE（年龄），代码修改如下：
改结构体： 在 C 语言的 struct MyRecord 中间手动插入一个 int age;。
改循环索引： 传统的硬编码循环通常长这样
int col_idx = 0;
while ((token = strtok(NULL, ","))) {
    if (col_idx == 0) record.id = atoi(token);
    else if (col_idx == 1) strcpy(record.name, token);
    // 原来的 col_idx == 2 是 ADDRESS，现在对不上了！
    else if (col_idx == 2) record.age = atoi(token); // 必须硬塞一行
    else if (col_idx == 3) strcpy(record.address, token); // 后续所有索引数字全部往后挪！
    col_idx++;
}

2 脆弱的“状态依赖”与数据污染
---
文本驱动的解析器，其状态完全依赖于“当前字符串里逗号的绝对个数”。它对输入数据的容错率几乎为零。
列顺序调换即灾难： 如果上游系统升级，导出的列顺序从 [ID, NAME, AGE] 变成了 [AGE, NAME, ID]（字段数量没变，只是顺序变了）。
后果： 硬编码解析器完全无感，它依然会按照 col_idx == 0 去解析第一个字段。结果就是把 AGE（比如文本 "25"）当成 ID 读入，把 ID（比如文本 "100234"）当成 AGE 读入。

3 “代码膨胀”与认知负载
---
如果这张表不是 3 个字段，而是现代企业级数仓中常见的 100 个字段、200 个字段呢？
-代码怪兽： 你的解析核心循环里将会充斥着一个几千行的巨大 switch-case 块，或者上百个 if-else 分支。
-清洗规则与业务逻辑混杂： 每一列往往还伴随着非标清洗逻辑（比如：如果是日期列要格式化，如果是字符串要截断尾部空格）。这些清洗逻辑被迫全部堆在这个巨大的 while 循环里。
-无法维护： 这个循环会变成全公司没人敢动、没人能看懂的“核心禁区”。新员工想加个字段，根本理不清上百个分支之间的上下文关系，认知负载直接爆表。

【 在 ylh1969 的大作中提到: 】
: 过奖，我是十年磨一剑慢工细活，愿赠予识货者。
: 现代技术飞速发展，我落伍了，拿出想法，供你们之后需要之时参考，甚幸。
--
FROM 61.185.160.*