先查三件事：数据库邮件是否启用、msdb是否设为trustworthy on、执行账号是否在databasemailuserrole角色中；再检查环境差异与系统表错误日志。

SQL Server 里 sp_send_dbmail 发不出邮件？先查这三件事

绝大多数“存储过程发不了邮件”的问题，根本不在存储过程本身，而是 sp_send_dbmail 的前置条件没满足。它不报错、不抛异常，只默默静默失败——这是最坑的点。

• 数据库邮件配置是否启用：sysmail_start_sp 必须已执行（不是装完就自动开）
• msdb 数据库是否设为信任（TRUSTWORTHY ON）？尤其在使用 EXECUTE AS USER 场景下，否则权限链断裂
• 当前执行账号是否在 DatabaseMailUserRole 角色中？注意：不是 sysadmin 就自动有权限

存储过程中调用 sp_send_dbmail 的安全写法

直接拼接字符串传给 @body 或 @subject 很危险，容易被 SQL 注入，也难调试。更稳妥的方式是用变量 + CONCAT 或 FORMATMESSAGE 构造内容。

• 避免在 @body 中硬写单引号嵌套，改用双单引号转义或变量拼接
• @profile_name 必须显式指定，不能依赖默认值；不同环境 profile 名可能不同（如 'ProdAlerts' vs 'DevMail'）
• 加 @mailitem_id 输出参数捕获 ID，后续可查 sysmail_mailitems 表确认是否入队成功

DECLARE @body NVARCHAR(MAX) = CONCAT('错误发生于：', GETDATE(), '，影响行数：', @affected_rows);
EXEC msdb.dbo.sp_send_dbmail
  @profile_name = 'AlertProfile',
  @recipients = 'ops@company.com',
  @subject = '【PROD】订单处理失败告警',
  @body = @body,
  @mailitem_id = @mail_id OUTPUT;

存储过程里发邮件失败却没提示？加这个兜底检查

sp_send_dbmail 返回值永远是 0（成功入队），不代表邮件真发出去了。真正失败发生在异步队列处理阶段，所以必须查系统表。

• 执行后立刻查 sysmail_faileditems，看 last_mod_date 是否在最近 1 分钟内有新增记录
• 结合 sysmail_event_log 查具体错误，常见如：The mail could not be sent to the recipients because of the mail server failure
• 不要只依赖 @@ERROR 或 TRY...CATCH，它们捕不到队列层错误

为什么测试能发、上线就静默？注意三个环境差异点

开发机上能跑通，放到生产存储过程里就失效，大概率栽在这几个地方：

• 数据库上下文切换：EXEC 调用时若未显式指定 msdb..sp_send_dbmail，可能因 USE db 切换导致解析失败
• 执行账号变化：SSMS 用 Windows 登录，而作业/应用连接用 SQL 登录账号，后者很可能没被加进 DatabaseMailUserRole
• 防火墙或 SMTP 策略：生产邮件服务器常限制 IP 白名单，DB 服务器 IP 可能未放行

最易被忽略的是：SQL Server Agent 作业运行时的上下文默认是 msdb，但普通存储过程调用不是。这点不验证，排查会绕半天。