before触发器中应使用json_valid()（mysql）或isjson()（sql server）校验json字段合法性，失败时用signal/throw抛出明确错误；必须先校验再提取，且需处理空字符串、bom等边界情况。
BEFORE INSERT/UPDATE 触发器中调用 JSON_VALID 或 ISJSON
MySQL 和 SQL Server 的触发器都能在数据写入前拦截并校验 JSON 字段。关键不是“能不能做”，而是“在哪做、怎么报错”。MySQL 用 JSON_VALID()，SQL Server 2016+ 用 ISJSON()，两者都返回整数，可直接用于条件判断。
常见错误是把校验逻辑放在 AFTER 触发器里——那时数据已落库，校验失败只能回滚事务，但错误信息无法透传给应用层；而 BEFORE 触发器中校验失败可直接用 SIGNAL（MySQL）或 THROW（SQL Server）抛出明确错误，应用能捕获并提示用户。
- MySQL 示例（5.7.22+）：
DELIMITER $$<br>CREATE TRIGGER chk_config_json BEFORE INSERT ON config<br>FOR EACH ROW<br>BEGIN<br> IF JSON_VALID(NEW.payload) = 0 THEN<br> SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'payload is not valid JSON';<br> END IF;<br>END$$<br>DELIMITER ;
- SQL Server 示例（2016+）：
CREATE TRIGGER chk_config_json ON config<br>BEFORE INSERT, UPDATE<br>AS<br>IF EXISTS (SELECT 1 FROM inserted WHERE ISJSON(payload) 1)<br> THROW 50000, 'payload is not valid JSON', 1;
- 注意：MySQL 的
JSON_VALID()对NULL返回NULL，需额外判断NEW.payload IS NOT NULL；SQL Server 的ISJSON(NULL)返回NULL，同样不能只写= 1，得写ISJSON(payload) = 1
触发器里别直接用 JSON_EXTRACT 或 -> 操作符做校验
有人想在触发器里顺手提取字段验证结构，比如 JSON_EXTRACT(NEW.payload, '$.timeout') 是否为数字。这很危险：只要 payload 不是合法 JSON，MySQL 就静默返回 NULL，SQL Server 则直接报错中断触发器执行——你根本等不到后续校验逻辑。
真正安全的顺序是：先过 JSON_VALID()/ISJSON() 这道关，再做提取或类型检查。否则，一次格式错误就会让整个 INSERT/UPDATE 失败且无明确原因。
- 错误写法（MySQL）：
IF JSON_EXTRACT(NEW.payload, '$.timeout') —— 若 payload 是 <code>'{timeout: abc}'，JSON_EXTRACT返回NULL，比较变成NULL ，结果为 <code>UNKNOWN，条件不成立，校验失效 - 正确写法：
IF JSON_VALID(NEW.payload) = 1 AND (JSON_EXTRACT(NEW.payload, '$.timeout') - PostgreSQL 用户注意：它没有
BEFORE行级触发器支持RETURN NULL阻断插入，得用INSTEAD OF或函数封装校验逻辑
空字符串、BOM、单引号 JSON 都会绕过基础校验
触发器里只写 JSON_VALID(NEW.payload) = 1 远不够。空字符串 ''、带 UTF-8 BOM 的字节序标记（\xEF\xBB\xBF{...}）、key 未加双引号的 {status: "ok"}，都会让 JSON_VALID() 返回 0 或 ISJSON() 返回 0，但这些情况往往来自前端低质量输入，需要更前置的清洗。
触发器不是清洗层，但可以加一层轻量预处理：比如 MySQL 中用 TRIM() 去首尾空白，SQL Server 中用 TRIM(NCHAR(65279) FROM payload) 清 BOM（U+FEFF），再送入校验函数。
- MySQL 安全模板：
IF JSON_VALID(TRIM(NEW.payload)) = 0 OR TRIM(NEW.payload) = '' THEN SIGNAL ... - SQL Server 注意：
ISJSON()对带 BOM 的字符串返回0，但不会报错，必须手动截掉；TRIM()在 2017+ 支持 Unicode，老版本得用REPLACE(payload, NCHAR(65279), '') - 别在触发器里尝试修复单引号 JSON（如把
{a:1}转成{"a":1}）——正则不可靠，且违反“触发器只校验、不改写”原则
触发器校验失败时，错误信息要具体到字段和原因
只抛 'Invalid JSON' 没用。前端提交了 2KB 的配置，用户根本不知道哪一行、哪个 key 出问题。MySQL 的 json_last_error_msg() 不可用在触发器里（它是会话级函数），SQL Server 也没有等价物，所以得靠外围手段补足。
可行做法是在触发器里先用 JSON_VALID() 快速兜底，若失败，再用应用层调用 json_decode($input, true, 512, JSON_BIGINT_AS_STRING) 并检查 json_last_error_msg()，把完整错误信息返回给用户。触发器只负责“拦住非法数据入库”，不负责“告诉用户怎么修”。
- 高频误判点：
'null'（字符串）是合法 JSON，JSON_VALID('null')返回1；但业务上可能不允许这个值，得额外加AND NEW.payload != 'null' - MySQL 8.0.22+ 支持
JSON_SCHEMA_VALID()，但触发器中调用性能差，且 schema 定义复杂，不建议在写入路径强依赖 - 真正难处理的是嵌套过深或超大 JSON（如 >1MB），触发器执行可能超时；这类应由应用层限长、分片、或走异步校验队列
