mysql函数中declare必须紧接begin后第一行，因解析器强制要求所有声明语句位于begin...end块最开头；局部变量作用域严格限定于所在块，不可跨块访问，且函数中禁用用户变量赋值参与返回计算。
MySQL函数中DECLARE必须写在BEGIN之后第一行
因为MySQL解析器强制要求所有DECLARE语句必须出现在BEGIN ... END块的最开头，紧接BEGIN之后、任何可执行语句（如INSERT、SELECT）之前。一旦出现任意一条非声明语句，后续再写DECLARE就会报错ERROR 1337 (42000): Variable 'xxx' is declared after other statements。
- 错误写法：先
INSERT再DECLARE→ 直接语法报错，函数创建失败 - 正确顺序：所有
DECLARE→ 所有可执行语句 →RETURN - 不支持“边用边声明”，也不允许把
DECLARE分散在逻辑中间
局部变量无法跨BEGIN END块访问
MySQL没有嵌套作用域支持，每个BEGIN ... END构成一个独立作用域边界。即使你在函数里写两层BEGIN END，外层声明的变量对内层不可见，内层声明的变量在外层也完全不存在。
- 常见误判：以为像JavaScript那样能向上查找 → 实际是彻底隔离
- 试图在子块中修改外层变量 → 报错
Unknown column 'xxx' in 'field list'或直接忽略赋值 - 如果真需要跨块传递值，只能靠
RETURN返回、或改用会话变量@var_name
函数体不是会话上下文，用户变量@var_name也不能随便用
虽然@var_name这种会话变量看起来能逃出作用域限制，但它在函数内部使用有严重限制：MySQL禁止在函数中对用户变量做赋值后再用于返回值计算（尤其涉及SELECT ... INTO @var），否则可能触发ERROR 1418 (HY000)——除非函数被标记为DETERMINISTIC且有SQL SECURITY DEFINER，但这样又带来安全与复制风险。
- 函数中允许读
@var_name，但写操作极易导致不可预测行为 -
SET @x = 1在函数里通常能执行，但后续RETURN @x可能返回NULL（取决于MySQL版本和binlog格式） - 真正可靠的数据暂存方式只有
DECLARE+ 严格前置声明 + 块内闭环使用
为什么不能像存储过程那样灵活？
MySQL对函数施加了比存储过程更严的限制，核心原因是函数要能安全用于SQL表达式（比如SELECT f1(col) FROM t）。它必须保证无副作用、可重复执行、不改变连接状态——所以禁止访问会话变量、禁止显式事务控制、也强制局部变量生命周期严格绑定到单次调用栈。
- 存储过程可以用
DECLARE+IF+ 多个BEGIN END嵌套，函数不行 - 函数中哪怕只多写一行
SELECT 1;，都可能导致某些变量初始化失效 - 调试时别依赖
SELECT输出看变量值——函数里SELECT不会返回结果集，只会静默失败或报错
