参数类型声明必须显式指定，不能依赖隐式转换：MySQL和SQL Server均要求IN/OUT/INOUT参数后明确标注类型（如IN p_phone VARCHAR(20)），避免字符串转INT截断、VARCHAR无长度默认为1等风险；所有参数须在BEGIN后首段校验空值、格式、范围及枚举值；OUT/INOUT参数需初始化并确保各分支赋值；过程末尾须显式RETURN状态码，调用端必须检查而非仅捕获异常。
参数类型声明必须显式指定，不能依赖隐式转换
MySQL 和 SQL Server 都支持在 CREATE PROCEDURE 中声明 IN、OUT、INOUT 参数及对应类型，但很多人直接写 IN p_id 而不带类型，结果触发隐式转换——比如把字符串 '123abc' 自动转成 INT 时截断为 123，脏数据已入库。
实操建议：
- 所有参数必须带明确类型，如
IN p_phone VARCHAR(20)、IN p_age TINYINT UNSIGNED - 对数值类参数，优先用带范围限制的类型（如
TINYINT而非INT），避免传入超限值被静默截断 - 字符串参数务必设长度上限，防止超长输入挤占日志或触发
max_allowed_packet错误 - SQL Server 中注意
VARCHAR不加长度默认是VARCHAR(1)，极易丢数据
在 BEGIN 前做参数合法性校验，别等 INSERT 时才报错
把校验逻辑放在 BEGIN 后第一段，而不是混在业务 SQL 里。否则像 INSERT INTO users (age) VALUES (@age) 这种语句，一旦 @age = -5 或 NULL（而字段定义为 NOT NULL），错误发生在执行层，无法区分是参数错还是表约束冲突。
常见校验点：
- 空值检查：
IF p_phone IS NULL OR TRIM(p_phone) = '' THEN RAISERROR('phone required', 16, 1); RETURN; END IF; - 格式检查：MySQL 8.0+ 可用
p_phone REGEXP '^[0-9]{11}$'；SQL Server 用LEN(p_phone) = 11 AND p_phone NOT LIKE '%[^0-9]%' - 范围检查：
IF p_age 150 THEN ... - 枚举值检查：
IF p_status NOT IN ('active', 'inactive', 'pending') THEN ...
OUT/INOUT 参数要初始化，否则返回 NULL 容易引发调用方误解
OUT 参数在过程内不赋值就会以 NULL 返回，而很多应用层代码没做 NULL 判断，直接当成功处理——比如清洗电话号失败却返回 NULL，上层以为“清洗完成”，实际字段仍是脏的。
正确做法：
- 声明后立刻初始化：
DECLARE p_result VARCHAR(20) DEFAULT 'failed'; - 所有分支路径都确保赋值，包括
ELSE和异常捕获块 - SQL Server 中
SET @p_result = 'success'必须显式执行，不能靠最后一条 SELECT 暗示 - 避免用
SELECT @p_result = ...从查询结果赋值，若查询无结果，变量保持旧值或NULL，状态不可控
调用端必须检查返回状态，不能只看是否抛异常
存储过程执行成功 ≠ 业务成功。比如一个清洗过程内部用 TRY...CATCH 吞了某行转换失败，但仍返回 0（表示执行完毕），调用方误判为全部 OK。
关键动作：
- 过程末尾用
SELECT或RETURN显式返回状态码，如RETURN 0（成功）、RETURN -1（参数错）、RETURN -2（部分数据跳过） - PHP/Java 调用时，必须读取
mysqli_affected_rows()或CallableStatement.getUpdateCount()，而非仅捕获 SQLException - 避免在过程中用
PRINT或RAISERROR代替状态返回——日志能看，但程序没法自动响应
IF，而是让每个参数的“合法边界”和业务规则对齐。比如手机号允许带 + 和国际区号，但清洗后必须归一为纯数字；又比如日期字段允许空，但一旦有值就必须是有效日期——这些规则得固化在过程开头，而不是靠下游补救。 
