Java调用存储过程必须使用CallableStatement并绑定参数，否则拼接SQL字符串将导致注入；真正风险在于存储过程内部是否禁用动态拼接、是否严格参数化执行。
Java 调用存储过程本身不防注入——关键在存储过程内部是否安全。只要存储过程里用了 EXEC 或 sp_executesql 拼接用户输入，Java 层再怎么用 CallableStatement 也救不了。
Java 层必须用 CallableStatement + 参数绑定
这是底线，不是可选项。直接拼接 SQL 字符串调用存储过程（比如 "{CALL proc_name('" + input + "')}"）等于把漏洞从数据库层搬到应用层。
- 必须用
CallableStatement，通过setString()、setInt()等方法传参，不能手动拼接参数值 - 调用语法要带问号占位符：
"{CALL GetUserByName(?)}"，而不是硬编码参数 - 避免用
executeUpdate("EXEC GetUserByName '" + name + "'")这类写法——这已经不是“调用存储过程”，而是“在 Java 里拼 SQL”
存储过程内部禁用字符串拼接，只用 sp_executesql + 参数化模板
很多人以为 Java 层安全了就万事大吉，其实真正的风险藏在存储过程里。动态 SQL 只能走 sp_executesql，且必须满足三要素：SQL 模板不含用户输入、参数定义明确、值单独绑定。
- 错误写法：
DECLARE @sql NVARCHAR(MAX) = 'SELECT * FROM users WHERE name = ''' + @name + ''''; EXEC(@sql)—— 单引号拼接，100% 可注入 - 正确写法：
DECLARE @sql = 'SELECT * FROM users WHERE name = @n'; EXEC sp_executesql @sql, N'@n NVARCHAR(50)', @n = @name -
sp_executesql的第二个参数（类型声明）不能是拼出来的，比如N'@n ' + @type就又退化成拼接
表名/列名等标识符必须白名单校验 + QUOTENAME()
参数化查询对值有效，对对象名无效。如果业务真要动态指定表或排序字段，必须收口，不能放任自由输入。
立即学习“Java免费学习笔记（深入）”；
- 先查系统视图确认存在：
IF NOT EXISTS (SELECT 1 FROM sys.tables WHERE name = @table_name AND schema_id = SCHEMA_ID('dbo')) THROW 50000, 'Invalid table', 1; - 白名单判断比
OBJECT_ID(@name)更可靠，后者可能被截断绕过 - 校验通过后，用
QUOTENAME(@col)包裹再拼进 SQL，例如：'ORDER BY ' + QUOTENAME(@sort_col) -
QUOTENAME()不是万能的，它不处理 Unicode 零宽字符或嵌套括号，所以前置白名单仍是刚性要求
警惕 Java 和数据库双层隐性拼接点
容易被忽略的地方往往最危险。比如 MyBatis 的 ${} 语法、JDBC 的 setObject() 误传 SQL 片段、甚至存储过程中用 CONTEXT_INFO 传递未校验的上下文数据，都可能成为注入跳板。
- MyBatis 调用存储过程时，XML 中不要出现
${procName}或${whereClause}—— 这些全是高危点 - Java 层传入的参数，如果在存储过程中被用于构建
OPENROWSET或OPENDATASOURCE连接字符串，同样需要重校验 - 临时表名、CTE 别名、提示（hint）内容，凡涉及运行时构造 SQL 结构的部分，都要按标识符规则处理
真正难的不是写对一行 sp_executesql，而是确保所有动态分支路径——包括错误处理里的日志拼接、调试开关下的条件 SQL、甚至 DBA 手动加的监控语句——全都遵守同一套参数化原则。任何一处松动，整条链路就失效。
