utl_mail不能直接在exception块中裸调用发警报，因其依赖网络连通性、用户权限及smtp_out_server参数配置三者就绪，缺一即导致ora-29279或ora-24247错误；须先验证db服务器到smtp的telnet连通性，确认包已安装、授权且配置正确，并在独立begin...exception中安全调用，避免参数格式错误引发静默失败。
utl_mail 不能直接在 exception 块里“裸调用”就发警报——它依赖网络、权限、配置三重就绪，缺一不可，否则静默失败或抛 ora-29279/ora-24247。
确认数据库服务器能连通 SMTP 服务器
UTL_MAIL 不走客户端网络，只走 DB Server 的 outbound 路径。调用 UTL_MAIL.SEND 前，必须在数据库服务器操作系统上验证连通性：
- 执行
telnet smtp.company.local 25（或 587、465，按实际端口） - 超时或
Connection refused？说明防火墙、ACL、DNS 或 SMTP 地址配置已阻断 - 企业内网常见情况：DB Server 禁外网，只能连内部中继（如
mail-relay.internal），别填公网 SMTP - Gmail / Outlook 等云邮箱默认要求 STARTTLS 或 SSL，
UTL_MAIL不支持——它只认明文 SMTP，587 端口若强制加密会直接报ORA-29279
检查 UTL_MAIL 是否安装、授权且参数已设
包没装、用户没权、smtp_out_server 没配，调用必失败：
- 查包是否存在：
SELECT object_name FROM dba_objects WHERE object_name = 'UTL_MAIL' AND status = 'VALID'; - 查当前用户权限：
SELECT * FROM dba_tab_privs WHERE table_name = 'UTL_MAIL' AND grantee = 'YOUR_USER'; - 查 SMTP 配置：
SHOW PARAMETER smtp_out_server；若为空，需 DBA 执行：ALTER SYSTEM SET smtp_out_server='10.1.2.55' SCOPE=BOTH; - Oracle 11gR2+ 支持动态修改，旧版本可能需
SCOPE=SPFILE并重启
在存储过程 EXCEPTION 中安全调用 UTL_MAIL.SEND
直接写 UTL_MAIL.SEND(...) 容易因参数格式错、空值、特殊字符导致静默丢信或 ORA-29260：
-
sender和recipients必须是完整邮箱格式，如'alert@company.com'，不能只写用户名 - 多个收件人用英文逗号分隔，末尾严禁空格：
'a@x.com,b@y.com'✅，'a@x.com, b@y.com'❌ -
subject中避免换行（CHR(10)）、制表符、中文引号；建议预处理：REPLACE(p_subject, CHR(10), ' ') - 邮件正文若含
、<code>&等 HTML 字符，SMTP 可能解析异常；纯文本场景下，直接拼接字符串比用UTL_RAW.CAST_TO_VARCHAR2更稳妥 - 务必把
UTL_MAIL.SEND包在独立的BEGIN...EXCEPTION块里，避免警报失败拖垮主逻辑
替代方案：UTL_SMTP 更可控但更复杂
当 UTL_MAIL 因认证、加密、附件等需求不满足时，UTL_SMTP 是唯一出路——但它不自动处理 Base64 编码、MIME 头、STARTTLS 协商：
- 必须显式调用
UTL_SMTP.EHLO（不是HELO），否则报ORA-29279: 503 Send hello first - 若 SMTP 要求登录，得手动做 Base64 编码：
UTL_ENCODE.BASE64_ENCODE(UTL_RAW.CAST_TO_RAW(v_user)) - 邮件头与正文之间必须有且仅有一个空行（
UTL_TCP.CRLF || UTL_TCP.CRLF），少一个就收不到 - 中文主题需额外处理编码（如
=?UTF-8?B?...），否则乱码；正文用UTL_SMTP.WRITE_RAW_DATA+UTL_RAW.CAST_TO_RAW更可靠
真正卡住的从来不是语法，而是 DB Server 到 SMTP 的那条 TCP 连接——连不上，所有参数和代码都白搭。每次改完配置，先登服务器 telnet 一把，比反复重试存储过程快十倍。
