通用可复用存储过程靠明确边界、参数化控制和拒绝隐式依赖实现，而非宽泛编写；需严格设计参数、限定作用域、轻量事务处理，并部署前验证兼容性、对象存在性及边界输入。
通用且可复用的存储过程不是靠“写得宽泛”实现的，而是靠明确边界、参数化控制、拒绝隐式依赖来达成。硬塞一堆 IF 判断或动态拼接，反而让过程难以测试、调试和授权。
参数设计必须严格区分用途和方向
一个存储过程是否容易复用，第一眼就看参数列表：是否所有外部可变因素都暴露为参数？是否混用了业务逻辑判断和数据筛选？
-
@dept_id是合理输入参数；@include_inactive（bit 类型）也是，它把“是否查禁用员工”这个开关交由调用方决定 - 但
@sql_filter（varchar）这种字符串参数就是危险信号——它诱导你写EXEC(@sql)，直接绕过参数化，埋下 SQL 注入和执行计划缓存失效的隐患 - 输出参数只用于返回单值状态或聚合结果（如
@total_count INT OUTPUT），别试图用它返回结果集；结果集靠 SELECT 直出，这是 SQL Server 和 MySQL 的通用契约
避免在过程中做跨表/跨库的隐式假设
所谓“通用”，不等于“自动适配任意表结构”。很多团队写的“通用分页过程”，内部硬编码 SELECT * FROM @table_name，却没校验该表是否存在、字段是否可排序、主键类型是否匹配——这类过程上线后基本只能靠人肉改。
- 真正可复用的做法是：限定作用域。例如只支持
Employees、Products这类有标准主键（id INT）和时间字段（created_at DATETIME）的表，并在开头用IF NOT EXISTS (SELECT 1 FROM sys.tables WHERE name = 'Employees')做存在性检查 - 不要在过程里写
INSERT INTO LogTable这种跨业务域的操作；日志应由调用方控制，或通过扩展事件/触发器解耦 - 如果真需要多表支持，用明确的枚举参数（如
@target_table VARCHAR(20) = 'Employees'），配合 CASE 分支处理，而不是靠字符串拼接
事务与错误处理不能省，但要轻量
复用过程一旦卷入事务，就必须明确定义它的原子性边界。很多人加了 BEGIN TRY ... COMMIT 却忘了：这个过程是被别人调用的，它不该擅自 COMMIT 或 ROLLBACK 外层事务。
- 推荐模式：
SET XACT_ABORT ON+THROW。前者确保语句失败时自动回滚当前事务上下文；后者把错误原样抛出，由调用方决定如何处理 - 避免在过程里写
SAVE TRANSACTION或嵌套事务标记——除非你明确知道调用链中不会出现EXEC usp_A; EXEC usp_B这种串行调用 - 输出参数可用于传递非异常状态，比如
@result_code INT OUTPUT：0=成功，-1=记录不存在，-2=权限不足。这比依赖@@ERROR更稳定、更易测试
部署前必须验证三件事
再“通用”的存储过程，脱离具体数据库实例就只是文本。上线前漏掉任何一项，都会导致复用失败。
- 确认目标数据库的兼容级别（SQL Server 的
COMPATIBILITY_LEVEL）、排序规则（COLLATION）是否影响字符串比较逻辑 - 检查所有引用的对象（表、视图、函数）是否在目标库中存在且权限正确；特别注意跨 schema 引用，如
dbo.Employees写成Employees在某些权限模型下会失败 - 用最小数据集跑通所有参数组合：空参数、边界值（如
@page_size = 0）、NULL 输入——很多过程在 NULL 传入时因未加IS NULL判断而静默返回空结果
最常被忽略的点：复用不等于“一次编写，到处 deploy”。哪怕参数、逻辑完全一致，不同环境的统计信息、索引策略、内存配置也会让同一个存储过程表现迥异。上线后盯住执行计划，而不是只看“能跑通”。
