嵌套函数只生效最外层是误解，实际自内而外求值；问题多源于null传播、大小写敏感性、不可见字符及方言差异，需针对性处理类型、null和正则调用方式。
嵌套 REPLACE 时为什么只生效最外层？
因为 SQL 的函数调用是自内而外求值的，但很多人误以为写成 REPLACE(REPLACE(col, 'a', 'b'), 'c', 'd') 就能“链式替换”，其实它完全合法且正常工作——问题往往出在空格、大小写、不可见字符或 NULL 传播上。
- 如果
col是NULL，整个表达式结果就是NULL，中间所有REPLACE都不执行；加COALESCE(col, '')预处理更稳妥 - MySQL 中
REPLACE区分大小写（取决于列排序规则），REPLACE('Abc', 'a', 'X')在utf8mb4_0900_as_cs下不匹配，但utf8mb4_0900_ai_ci下会匹配 - PostgreSQL 不带
REPLACE的大小写模糊版本，得用REGEXP_REPLACE配合'i'标志
CONCAT 嵌套里 NULL 怎么不吞掉整条结果？
几乎所有 SQL 方言中，CONCAT(NULL, 'a', 'b') 返回 'ab'（MySQL/PostgreSQL 默认行为），但 NULL || 'a' || 'b'（PostgreSQL 标准拼接）或 CONCAT_WS 外的裸 || 一旦遇到 NULL 就整体变 NULL。
- MySQL 8.0+ 推荐统一用
CONCAT，它自动跳过NULL；5.7 及以前建议用CONCAT(COALESCE(a,''), COALESCE(b,'')) - PostgreSQL 想安全拼接，优先选
CONCAT(a, b, c)而非a || b || c，前者对NULL友好 - SQL Server 必须用
CONCAT()函数，+运算符遇到NULL直接返回NULL，没有例外
用 REGEXP_REPLACE 做多级清洗，为什么正则嵌套不生效？
REGEXP_REPLACE 本身不支持“在替换字符串里再写正则”，所谓“嵌套”其实是多次调用函数，不是语法嵌套。常见错误是试图在一个调用里用 \1 引用另一个正则的捕获组，这不可能发生。
- 想先删 HTML 标签、再压缩空白、最后转小写？必须三层嵌套：
LOWER(TRIM(REGEXP_REPLACE(REGEXP_REPLACE(text, ']+>', ''), '\s+', ' '))) - MySQL 8.0 的
REGEXP_REPLACE不支持g标志（全局替换默认开启），但 PostgreSQL 需显式加'g'，漏写就只换第一个匹配 - Oracle 的
REGEXP_REPLACE第四个参数是起始位置，第五个是出现次数，不填默认全量；少传参数会导致静默截断或报错ORA-12726
JSON 字段里取嵌套字符串，->> 和 -> 混用容易丢数据
PostgreSQL 和 MySQL 8.0+ 都支持 ->（返回 JSON 类型）和 ->>（返回 TEXT 类型），但嵌套访问时类型不一致会触发隐式转换失败或意外截断。
- 假设字段
data存{"user": {"name": "Alice", "tags": ["v1", "v2"]}}，data->'user'->>'name'正确；但data->>'user'->>'name'报错，因为->>返回字符串，不能再用-> - MySQL 中
JSON_EXTRACT(json_col, '$.user.name')和json_col->>'$.user.name'等价，但后者在字段为NULL时返回NULL，前者可能返回NULL或空字符串，取决于 JSON 解析状态 - PostgreSQL 里
jsonb_path_query_first(data, '$.user.tags[*] ? (@ == "v1")')这种路径查询比多层->更稳，尤其当结构不确定时
多重嵌套真正难的不是写法，而是每层函数的返回类型、NULL 处理策略、方言差异这三块边界经常被当成“应该一样”而忽略。实际跑之前，先用常量字符串试一遍嵌套链，比对着文档猜强得多。
