REPLACE不识别\n转义序列，必须用CHAR(10)/CHR(10)等字面值；不同数据库写法各异，且需同时处理CR、LF、TAB及Unicode换行符，NULL值须用COALESCE兜底。
REPLACE不识别\n这类转义写法
你在WHERE或REPLACE里写'\n'，数据库几乎肯定不会匹配到真实换行符——它只是两个字符：反斜杠和字母n。SQL标准不把\n当换行符解析，除非你显式启用转义字符串（如PostgreSQL的E'\n'）或数据库版本/模式特殊支持。直接写CHAR(10)或CHR(10)才真正对应LF字节。
不同数据库对换行符的表示不统一
同一段SQL在MySQL、PostgreSQL、SQL Server里可能失效，只因字符字面量写法不同：
- MySQL用
CHAR(10)、CHAR(13)；也可用UNHEX('0A') - PostgreSQL必须用
CHR(10)或E'\n'，写'\n'无效 - SQL Server支持
CHAR(10)，但TEXT类型字段需先CAST为VARCHAR(MAX) - SQLite不支持
CHAR()函数，得用X'0A'（十六进制）
你以为删了换行，其实还有别的不可见字符
只处理CHAR(10)和CHAR(13)远远不够。常见漏网之鱼包括：
-
CHAR(9)（制表符），尤其来自Excel粘贴或富文本编辑器 - Unicode换行符：
U+2028（LINE SEPARATOR）、U+2029（PARAGRAPH SEPARATOR），REPLACE完全无法匹配 - Windows下常是
CHAR(13)+CHAR(10)组合，单删一个，另一个仍残留 - 某些系统插入
CHAR(11)（垂直制表）或CHAR(12)（换页），也得单独处理
NULL值会让整个REPLACE结果变NULL
只要REPLACE任一参数是NULL，结果就是NULL，且不报错。字段本身为空、WHERE条件里用了IS NULL但没兜底，都会导致清洗后整列消失。必须提前用COALESCE(column_name, '')或ISNULL(column_name, '')包一层，再进REPLACE。
JSON_VALUE或OPENXML解析失败。这种字段得先判断是否承载结构化内容，不能无差别清洗。 
