SQL Server触发器不支持正则替换，需用INSTEAD OF触发器+递归CTE模拟或改用应用层清洗。其原生无REGEXP_REPLACE，REPLACE仅支持固定字符串，PATINDEX+STUFF效率低，CLR函数虽可行但部署复杂。
SQL Server 原生不支持在触发器里直接用正则替换——它没有 REGEXP_REPLACE 函数，也没有 ~ 或 REGEXP 运算符。想在 BEFORE INSERT 阶段做类似清洗，必须绕道实现，且代价明确：要么开启高危组件，要么写复杂 SQL 逻辑，要么干脆换路子。
SQL Server 触发器里没法直接写 REGEXP_REPLACE
MySQL 8.0+ 和 PostgreSQL 可以直接在 BEFORE INSERT 触发器里写 SET NEW.col = REGEXP_REPLACE(NEW.col, '\s+', ' ')，但 SQL Server 不行。它的 INSERT 触发器是 AFTER 或 INSTEAD OF 类型，且所有字符串函数（REPLACE、TRIM、LOWER）都不支持正则语法。
-
REPLACE()只能做固定子串一对一替换，无法处理“多个空格→一个空格”或“非数字字符全删”这类模式 -
PATINDEX('%[^a-z]%', col)能定位非法字符位置，但不能直接替换；配合STUFF()循环处理效率极低，且无法递归 - 试图在触发器里调用自定义 CLR 函数或
sp_OACreate创建 VBScript.RegExp 对象，会触发Msg 15281错误，除非手动启用Ole Automation Procedures（生产环境通常禁用）
INSTEAD OF 触发器 + 递归 CTE 是最可行的纯 T-SQL 方案
如果坚持用触发器拦截并清洗，INSTEAD OF INSERT 是唯一可写入的入口。清洗逻辑得靠递归 CTE 模拟“逐字符扫描+条件替换”，适用于中低频写入场景。
- 把原始插入数据先塞进临时表或表变量，再用递归 CTE 拆解字符串，每次迭代处理一个待替换字符（如
@charsToReplace中的每个符号） - 最终拼回清洗后字符串，再
INSERT INTO target_table—— 注意：这会丢失原语句的IDENTITY自增行为，需显式处理 - 示例核心逻辑：
WITH ReplaceCTE AS (SELECT @input AS str, 1 AS pos UNION ALL SELECT STUFF(str, pos, 1, @replacement), pos + 1 FROM ReplaceCTE WHERE CHARINDEX(SUBSTRING(@charsToReplace, pos, 1), str) > 0)，实际需更严谨的终止条件 - 性能敏感？别用。1000 行插入可能拖慢 3–5 倍；字段含中文或长文本时，CTE 层级深度易超默认 100 限制，得加
OPTION (MAXRECURSION n)
真正稳定的替代路径：别硬塞进触发器
触发器不是数据清洗的合理边界。尤其当清洗涉及正则、多步转换或失败重试时，它只会把问题从应用层转移到数据库事务里，还难调试。
- 应用层统一处理：在 C# 的 ORM（如 EF Core）
SaveChanges前遍历实体，用Regex.Replace()清洗，日志/异常/重试都可控 - 中间表 + SQL Agent 作业：原始数据先
INSERT INTO raw_orders，再由定时作业跑清洗脚本落clean_orders，失败可查日志、人工补数 - SQL Server 2022+ 可考虑
GENERATE_SERIES+STRING_AGG替代部分递归逻辑，但仍无法替代真正正则语义 - 若必须用数据库内正则，CLR 函数是唯一原生支持方式，但需 DBA 审批、代码签名、权限配置，上线流程重
正则清洗的「自动」感，往往来自应用层或调度层的封装，而不是触发器里那一行伪代码。SQL Server 的触发器适合补默认值、校验长度、简单大小写转换；一旦出现 [^\w\u4e00-\u9fa5] 这类表达式，就该让出控制权了。
