sql server存储过程中日期转换报错241的根源是会话language设置导致英文缩写（如jan）无法识别，应使用convert(date, @str, 样式码)显式转换并避免依赖隐式解析。
直接执行没问题，但放进存储过程里就报错 消息 241,级别 16,状态 1 ——这不是语法错，是会话语言环境没对上。
SQL Server 中英文日期字符串在存储过程里转不了
根源在于：SQL Server 解析 mon dd yyyy（如 Jan 01 2023）这类格式时，依赖当前会话的 LANGUAGE 设置。SSMS 默认用登录用户的语言（常为中文），而中文环境下 SQL Server 不认 Jan 这种缩写，直接抛 消息 241。
- 验证当前语言：
SELECT @@LANGUAGE，大概率返回Chinese - 临时改语言（不推荐长期用）：
SET LANGUAGE English放在存储过程开头 - 更稳妥的做法：别依赖隐式转换，统一用
CONVERT或PARSE显式指定样式 - 例如：
CONVERT(DATE, @input_str, 100)（样式 100 对应mon dd yyyy格式，且不受语言影响）
存储过程里用 CONVERT 转日期必须带样式码
CONVERT 第三个参数（样式码）不是可选的——尤其对非标准格式。漏掉它，SQL Server 就按当前语言+默认样式猜，一猜一个错。
- 常见英文日期格式对应样式码：
100（Jan 1 2023 1:02PM）、101（01/01/2023）、120（2023-01-01 01:02:03） - 如果输入是
'01-Jan-2023'，用106；'2023Jan01'这种就得先字符串处理，再拼成标准格式 - SQL Server 2012+ 可用
TRY_CONVERT(DATE, @str, 100)，失败返回NULL而非报错，适合容错场景
参数嗅探 + 日期转换 = 隐形雷区
即使你用了 CONVERT，如果存储过程被参数嗅探缓存了错误的执行计划，也可能在某次调用时突然失败——比如首次执行传入的是合法日期字符串，后续传入空值或格式混乱的字符串，而计划复用导致类型推导出错。
- 加
WITH RECOMPILE是最直白的验证手段，但别长期开着 - 更实用的写法：把输入参数赋给局部变量再转换，断开嗅探链，例如
DECLARE @dt DATE = TRY_CONVERT(DATE, @input_date_str, 100);
然后用@dt做后续逻辑 - 注意
TRY_CONVERT返回NULL，记得判空，否则WHERE date_col = @dt可能变成WHERE date_col = NULL（永远不成立）
真正麻烦的不是转换函数怎么写，而是同一个字符串在 SSMS 里能转、进存储过程就崩——问题往往藏在会话设置和执行计划缓存里，而不是代码本身。
