优先用 CONVERT，性能高且兼容性好；FORMAT 仅适用于展示层，因性能差且导致索引失效。CONVERT 需显式指定 style 和长度，避免默认值引发格式混乱或截断。
CONVERT 和 FORMAT 都能转日期为字符串，但选哪个、怎么用、为什么有时出错——得看具体场景和 SQL Server 版本。2012 以前只能用 CONVERT；2012+ 虽然多了 FORMAT，但它不是万能替代品，反而可能拖慢查询。
CONVERT 函数：快、稳、兼容性好，但格式代码得记牢
CONVERT 是最主流的选择，尤其在 WHERE 或 JOIN 中做隐式转换或格式化输出时，性能几乎无损耗。
- 格式代码是硬编码数字，比如
23对应'YYYY-MM-DD'，120对应'YYYY-MM-DD HH:MI:SS'，112对应'YYYYMMDD' - 目标类型必须显式指定长度，
CONVERT(VARCHAR(10), GETDATE(), 23)比CONVERT(VARCHAR, GETDATE(), 23)更安全（后者可能截断） - 不支持本地化，比如“二〇二六年五月十八日”或“May 18, 2026”这种写法无法直接实现
- 错误常见于 style 值填错，例如用
105（印度格式）却期望输出中文，结果是'18-05-2026'，不是你想要的
FORMAT 函数：灵活但慢，别在 WHERE 条件里用
FORMAT 的语法更接近 C#，写起来直观，比如 FORMAT(GETDATE(), 'yyyy-MM-dd')，但代价明显：
- 所有输入都会被转成
NVARCHAR，且内部依赖 CLR，执行开销比CONVERT高 3–5 倍（实测大数据量分页查询时延迟翻倍） - 在
WHERE子句中用FORMAT(order_date, 'yyyyMM') = '202605'会导致全表扫描——因为无法走order_date字段的索引 - 支持
culture参数，如FORMAT(GETDATE(), 'D', 'zh-CN')输出“2026年5月18日 星期一”，但注意：该参数必须是字符串字面量，不能是变量 - 返回 NULL 而非报错：当传入非法日期（如
'2026-02-30'）时静默返回NULL，容易掩盖数据质量问题
什么时候必须用 CONVERT，什么时候可以换 FORMAT
实际开发中，判断依据不是“哪个新”，而是“在哪用”和“谁读”。- 报表导出、前端展示层格式化：优先
FORMAT，可读性强，维护成本低 - 查询条件、聚合分组、JOIN 关联字段：必须用
CONVERT，或更好——直接用日期函数（如YEAR()/MONTH()）避免转换 - 需要补零、拼接自定义符号（如
'第' + CAST(MONTH(GETDATE()) AS VARCHAR) + '月'）：CONVERT+REPLACE或STUFF更可控，FORMAT的占位符不支持逻辑分支 - 兼容 SQL Server 2008/2012 旧环境：只能靠
CONVERT，别碰FORMAT
一个容易被忽略的坑：CONVERT 的 style 默认值是 0 或 100
没写 style 参数时，CONVERT(VARCHAR, GETDATE()) 实际等价于 CONVERT(VARCHAR, GETDATE(), 0)，输出类似 'May 18 2026 2:59PM' —— 这种格式既难解析又不便于排序。生产环境务必显式指定 style，哪怕只是为了防止某天服务器区域设置变更导致输出突变。
真正麻烦的不是不会写，而是写了之后在 WHERE 里用了 FORMAT 却没意识到它让索引失效，或者在高并发报表接口里把 CONVERT 写成 CONVERT(VARCHAR, date_col, 120) 却忘了加长度，结果 varchar 被截成 '2026-05-18 14:'。
