TRY_CONVERT不报错但需主动处理NULL，WHERE中过滤比ISNUMERIC更可靠，样式码影响解析结果，大表查询应避免直接使用以防全表扫描，且不校验业务规则仅作安全转换。
TRY_CONVERT在存储过程中不报错，但NULL要主动处理
直接把TRY_CONVERT塞进INSERT或UPDATE语句里，它确实不会中断执行——可如果目标列不允许NULL，或者后续逻辑没检查结果，就会在别处崩。比如往INT NOT NULL字段插TRY_CONVERT(INT, 'abc')，得到NULL后直接触发“不能插入NULL”错误。
必须显式兜底：COALESCE(TRY_CONVERT(INT, @input), 0)补默认值，或用CASE WHEN TRY_CONVERT(...) IS NULL THEN ... ELSE ... END分流处理。别指望TRY_CONVERT自己解决业务语义问题。
WHERE里用TRY_CONVERT过滤，比ISNUMERIC靠谱得多
ISNUMERIC()返回1的字符串，TRY_CONVERT(INT, ...)大概率是NULL——比如'.'、'e'、'$100'。用ISNUMERIC(x) = 1 AND TRY_CONVERT(INT, x) IS NOT NULL纯属多此一举，还拖慢查询。
直接写：WHERE TRY_CONVERT(DATE, date_str, 120) IS NOT NULL，既过滤非法格式，又排除逻辑无效日期（如'2023-02-30'）。注意样式码120强制按yyyy-mm-dd解析，避免语言设置干扰。
-
TRY_CONVERT(DATE, '01/02/2023', 101)在us_english下是2023-01-02，在British下是2023-02-01——样式码不匹配就不可控 - 对纯数字字符串，
style参数被忽略，传不传都一样
大表查询中反复调用TRY_CONVERT会拖垮性能
在WHERE子句里对非索引字段写TRY_CONVERT(INT, col)，SQL Server无法走索引，必然全表扫描。尤其当表有千万级数据时，响应时间从毫秒跳到分钟。
两个更优解：
- 如果该字段本应存数字，建一个持久化计算列：ALTER TABLE logs ADD safe_amount AS TRY_CONVERT(INT, amount_str) PERSISTED，再给这个列建索引
- 或先用轻量级筛选缩小范围：WHERE amount_str LIKE '[0-9]%' AND amount_str NOT LIKE '%[^0-9]%' AND TRY_CONVERT(INT, amount_str) IS NOT NULL
TRY_CONVERT不校验闰年、月份天数等业务规则，但会返回NULL
TRY_CONVERT(DATE, '2023-02-29', 120)返回NULL（2023不是闰年），这没问题；但TRY_CONVERT(DATE, '2023-00-01', 120)也返回NULL，而TRY_CONVERT(DATE, '2023-13-01', 120)同样NULL——它只做格式+日历合法性检查，不做字符串正则校验。
这意味着：你不能靠它区分“格式错”和“日期不存在”。如果业务要求标记具体错误类型（比如“月份超出1-12”或“2月天数超限”），得额外加PATINDEX或SUBSTRING拆解字符串判断，TRY_CONVERT只负责最后一道安全阀。
