GOTO在SQL存储过程中非必需，仅限错误清理或提前退出等极少数场景使用；必须遵守标签唯一性、同作用域跳转、禁入声明区和HANDLER等严格规则。
GOTO 在 SQL 存储过程中不是必须的，绝大多数场景可用 IF/WHILE/REPEAT 替代；它只在极少数错误清理或提前退出逻辑中勉强可读，且必须严格遵守作用域限制。
SQL 存储过程里 GOTO 的合法写法和标签规则
标签必须是唯一标识符，用 <<label>> 语法定义（如 <<exit>>），不能是保留字（比如 exit 本身就不能当标签名）；GOTO label 必须与标签在同一个作用域内：
-
GOTO不能跳进IF、CASE或LOOP块内部 —— 即使标签写在块开头也不行 -
GOTO不能跳到声明区（DECLARE之后、第一个可执行语句之前） - 标签不能定义在
HANDLER（异常处理块）内，而GOTO又在 handler 外 —— 这会报SQLSTATE 42736 - 标签后必须紧跟可执行语句，空标签（比如
<<done>>后直接END）会导致语法错误，需加NULL补位
常见错误现象：为什么一用就报错？
最常遇到的不是语法错，而是作用域越界或标签不可见：
-
GOTO exit;报错SQLSTATE 42736→ 标签<<exit>>没写，或写在了嵌套BEGIN ... END块外 -
Unexpected token "<<"→ 用了双尖括号但数据库不支持该语法（MySQL 完全不支持<<label>>，只认label:形式） - 程序跳转后部分变量未初始化就引用 → 因为
GOTO绕过了前面的DECLARE或赋值语句，但变量作用域仍存在，值为NULL - 事务没提交/回滚就跳走 →
GOTO不自动触发事务控制，必须手动加COMMIT或ROLLBACK在标签处
替代 GOTO 的更安全写法
真正需要“提前退出”或“统一收尾”的逻辑，优先用结构化方式实现：
- 用
IF ... THEN RETURN;直接终止（PostgreSQL / GaussDB 支持，SQL Server 用RETURN，MySQL 需封装在LEAVE块中） - 把清理逻辑抽成独立子过程，比如
cleanup_and_exit()，再用CALL cleanup_and_exit(); - 用布尔标志控制流程：
SET done = TRUE;+ 外层WHILE NOT done DO ... END WHILE; - 错误处理统一交给
DECLARE EXIT HANDLER（MySQL / PostgreSQL），而不是靠GOTO模拟
真要用 GOTO，只限这三种场景
如果评审已通过、旧系统无法重构，且满足以下全部条件，才考虑用：
- 目标是跳到存储过程末尾做统一
COMMIT/ROLLBACK和OUT参数赋值（如示例中的<<exit>>） - 所有跳转都发生在同一层
BEGIN ... END块内，无嵌套块干扰 - 标签位置明确位于过程靠后、变量均已声明、资源已分配完毕的位置
- 团队明确约定：每个存储过程最多一个
GOTO，且仅用于错误分支，不用于循环或正常流程控制
实际维护中，最难 debug 的往往不是逻辑本身，而是某次修改无意中让一个 GOTO 跳到了未初始化变量的上下文，或者跨块跳转被数据库 silently 忽略却没报错 —— 这类问题不会在开发期暴露，只在特定数据路径下触发。
