题目重点：从源列、目标列、类型转换和版本化契约出发，设计医疗数据表映射与对账流程。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 下文的 patientId、dateOfBirth 等字段是训练示例，不是题目所给实际 schema；敏感医疗数据应满足适用权限和审计要求。
- 映射配置包含源字段、目标字段、类型转换、必填/默认规则和版本；空值与错误行不能静默当成功。
解题路线
- 先获取双方 schema 和数据字典，不凭列名相似度直接配对；确认字段语义、单位、时区、枚举值和主键身份。例如 DOB 不是年龄，体温摄氏/华氏也不能只改列名。
- 将映射配置版本化：sourceColumn、targetColumn、transform、nullable、validation。加载时校验源列存在、目标列覆盖与转换类型兼容。
- 执行链路先读取并标准化，逐字段转换后做目标 schema 校验；无效行进入隔离队列，记录字段级原因和源记录 ID，避免整批丢失或静默错列。
- 迁移或持续同步时做行数、唯一键、关键字段非空率和抽样逐行对账；新旧 schema 并行运行，按版本回放与回滚。
- 对受保护数据只在授权环境保留最少信息，日志中不写明文敏感字段；审计谁改了映射、何时生效、影响哪些批次。
手动走一遍
假设源字段 birth_date 为 YYYY-MM-DD，目标字段 patientDob 为 DD-MM-YYYY。配置不只是重命名，还要解析并重新格式化；若源值为 2026-02-30，应拒绝该行并记录原因，不能直接复制非法日期。
规模与取舍
每行 F 个字段、N 行，基础转换 O(NF) 时间；映射配置 O(F)，批处理内存随 batch 大小 B 为 O(BF)。索引查找和外部 API 调用会增加成本，应单独量测。
易错点与追问
容易失分的边界
- 用字符串相似度自动映射列而不审查业务语义。
- 缺少映射版本，第三方改 schema 后无法重现历史结果。
- 错误行被忽略但成功计数仍包含它，导致下游医疗记录缺失而不报警。
- 在 debug 日志写入患者敏感字段。
继续深挖
- 第三方把单个姓名列拆成 given/family name，如何处理无法可靠拆分的记录？
- 如果同步延迟 24 小时，如何安全补跑且不重复写入？
- 哪些字段转换必须由业务或临床专家签字确认？
