通用数据清洗需限定输入结构、暴露控制开关、禁用动态SQL；参数应区分数据源与策略，用JSON或显式列名传递，避免表名硬编码；操作须确定性、可回滚、可预览；优先ANSI函数保障跨库兼容；复用靠原子化小过程组合而非大而全逻辑。
通用的数据清洗逻辑不能靠“一个过程包打天下”，而必须限定输入结构、暴露控制开关、拒绝字符串拼接式动态SQL——否则不是复用，是埋雷。
参数设计必须区分「数据源」和「清洗策略」
清洗过程不是ETL管道，它不负责决定从哪张表读、往哪张表写；它的职责是：给定一组字段，按指定规则处理。所以参数里不该出现@source_table或@target_table，而应是@input_json（描述字段名+清洗类型）或显式列出待处理列，如@col_name VARCHAR(128)、@clean_type TINYINT（1=trim, 2=to_lower, 3=nullify_empty等）。
常见错误是把清洗逻辑和调度逻辑混在一起：比如在过程里写SELECT * FROM @table_name再EXEC(@sql)——这既绕过参数化，又让执行计划无法复用，还极易被注入。
- 正确做法：调用方先查出要清洗的字段列表，再逐个传入清洗过程
- 如果真需批量字段处理，用JSON传递结构化描述，配合
OPENJSON()（SQL Server）或JSON_TABLE()（MySQL 8.0+）解析，而非字符串拼接 -
@clean_type建议用枚举值，避免传入'trim_and_lower'这类自由文本，后续扩展难、校验弱
清洗动作必须可预测、可回滚、不隐式改数据
一个清洗过程执行后，应该只影响你明确指定的字段和行，且行为稳定——今天跑和三个月后跑，结果一致。这就要求所有操作都基于确定性函数，禁用依赖会话状态或随机值的逻辑。
- 避免
GETDATE()直接参与清洗判断（如WHERE create_time > GETDATE() - 7），改用输入参数@as_of_date DATETIME2，方便测试与重放 - 所有
UPDATE必须带WHERE条件，且该条件能被索引覆盖；禁止无条件全表更新 - 涉及
NULL转换（如空字符串转NULL）时，先用SELECT预览影响行数，再执行；过程内可通过@dry_run BIT = 1开关控制是否真正提交 - 别在清洗过程里做
INSERT INTO audit_log——日志由调用方统一记录，否则清洗逻辑和审计耦合，权限、事务、性能都变复杂
跨数据库兼容性陷阱集中在字符串和日期函数
同一段清洗逻辑，在SQL Server、MySQL、PostgreSQL上跑，TRIM()语义可能不同（比如是否去全角空格），REPLACE()对NULL参数的处理也不同。硬写方言代码等于放弃通用性。
- 优先使用ANSI标准函数：
TRIM()、UPPER()、LOWER()、COALESCE()，它们在主流数据库中行为一致 - 避免
DATEADD()（SQL Server）、DATE_SUB()（MySQL）、INTERVAL（PostgreSQL）混用；统一用输入参数接收已计算好的时间边界值 - 正则替换（如清理手机号中的非数字字符）不要写进过程主体；提取为独立标量函数，各库单独实现，主过程只调用
clean_phone(@raw) - 若必须用数据库特有函数，用
CASE WHEN @@VERSION LIKE '%Microsoft%' THEN ...做运行时分支——但这是下策，应尽量前置到应用层判断
真正的复用发生在调用链，不在单个过程体内
最常被忽略的一点：所谓“通用清洗过程”，90%的价值来自它被多个上游任务稳定调用，而不是它自己有多“智能”。一个只做TRIM + UPPER的简单过程，只要参数清晰、行为确定、文档明确，就比一个塞了20种清洗模式却没人敢改的“超级过程”更可靠。
实际落地时，建议把清洗拆成原子级小过程：usp_clean_trim、usp_clean_nullify_empty、usp_clean_normalize_gender，再由外部调度脚本或父存储过程按需组合。这样每步可单独测试、授权、监控，出问题也能快速定位到具体环节，而不是面对一个500行的“清洗巨兽”反复猜哪里出了错。
