优先用 convert，它兼容所有 sql server 版本、性能稳定；format 仅适用于需本地化格式（如“2026年05月19日”）且版本≥2012的场景，但会拖慢存储过程性能。
直接结论：优先用 CONVERT，除非你明确需要自定义分隔符或本地化格式（如“2026年05月19日”），否则别碰 FORMAT —— 它在存储过程中会拖慢性能，且不支持所有 SQL Server 版本。
CONVERT 是存储过程里最稳的日期格式化选择
它从 SQL Server 2000 就存在，所有版本兼容；执行计划稳定，不会因格式代码变化导致隐式转换失败。关键在于：你传的格式代码必须匹配输入值的实际结构。
-
CONVERT(VARCHAR(10), @date, 23)→ 输出2026-05-19，适用于 WHERE 条件、JOIN 或导出文件名 -
CONVERT(VARCHAR(19), @date, 120)→ 输出2026-05-19 03:55:00，带空格、无毫秒，适合日志记录 - 如果 @date 是
NVARCHAR字符串（如'20260519'），必须先转成日期类型再格式化：CONVERT(VARCHAR(10), CONVERT(DATE, @date, 112), 23) - 错误高发点：用代码 103（
dd/mm/yyyy）去格式化'2026-05-19'这类字符串，SQL Server 会尝试按英国规则解析，可能报错或返回意外结果
FORMAT 函数只在特定场景下值得启用
它依赖 .NET 运行时，每次调用都触发 CLR 开销，在循环多、数据量大的存储过程中明显拖慢执行速度。但它能干 CONVERT 干不了的事：
- 输出中文格式：
FORMAT(@date, 'yyyy年MM月dd日')→2026年05月19日 - 带星期几：
FORMAT(@date, 'yyyy-MM-dd dddd')→2026-05-19 星期二 - 适配不同区域：
FORMAT(@date, 'D', 'zh-CN')→ 全中文长格式 - 注意：SQL Server 2012+ 才支持；如果目标库是 2008R2 或更早，
FORMAT直接报错Invalid object name 'FORMAT'
存储过程中日期转换最容易踩的三个坑
不是语法写错，而是逻辑链断裂导致运行时失败：
- 把
VARCHAR类型的日期字符串（如'05/19/2026'）直接喂给CONVERT(DATE, ..., 101)看似合理，但如果客户端连接的DATEFORMAT设置是dmy，SQL Server 可能误判为19/05/2026，再遇到 32 号就炸了 - 在
WHERE子句里对字段做CONVERT(VARCHAR, date_col, 23) = '2026-05-19'—— 这会让索引失效，应改用范围查询：date_col >= '2026-05-19' AND date_col - 用
FORMAT拼接动态 SQL 字符串时没加QUOTENAME或转义单引号，比如FORMAT(GETDATE(), 'yyyy-MM-dd''T''HH:mm:ss')中的''T''必须双单引号，漏一个就语法报错
真正麻烦的不是选哪个函数，而是得想清楚：这个格式化结果是给人看的，还是给另一个系统读的？前者可上 FORMAT，后者一律用 CONVERT + 标准代码，少留歧义空间。
