UTL_HTTP调用前须配置ACL权限，否则报ORA-24247；超32KB请求体需用CLOB分段WRITE_RAW发送；字符集须统一设为UTF-8；必须显式设超时并处理异常，避免连接耗尽。
UTL_HTTP 调用前必须配 ACL 权限
没配 ACL 就调用 UTL_HTTP，会直接报错 ORA-24247: network access denied by access control list (ACL)。这不是代码写错了，是 Oracle 硬性安全策略——默认禁止所有网络出向连接。
ACL 必须由 SYS 或具有 ADMINISTER DATABASE TRIGGER 权限的用户执行，普通开发账号无权创建或修改。常见操作包括：
-
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL创建新 ACL 文件（如'http_access.xml'） -
DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL绑定目标主机和端口（如'example.com'和80或443） -
DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE授予具体数据库用户'connect'和可选的'resolve'权限
注意：ACL 不支持通配符域名（*.api.example.com 无效），每个目标主机+端口组合需单独授权；HTTPS 的 443 端口也要显式添加，不能省略。
POST 请求体超过 32KB 必须用 CLOB + write_raw 分段发送
UTL_HTTP.WRITE_TEXT 最大只接受 32767 字节字符串，超长 JSON 或表单数据会截断或报 ORA-06502。直接拼接 VARCHAR2 构造请求体是常见翻车点。
正确做法是用 CLOB 存请求体，再通过 UTL_HTTP.WRITE_RAW 分块写入：
- 调用
UTL_HTTP.SET_HEADER(req, 'Content-Length', v_body_length)显式设长度（不能依赖chunked） - 禁用
Transfer-Encoding: chunked—— Oracle 11gR2+ 默认不支持，设了反而导致服务端解析失败 - 循环调用
DBMS_LOB.READ+UTL_HTTP.WRITE_RAW，每次读取 ≤32767 字节，offset手动累加 - 发完后立即
DBMS_LOB.FREETEMPORARY释放 CLOB，否则可能撑爆临时表空间
字符集与编码必须显式对齐
乱码几乎都源于三处不一致：UTL_HTTP.SET_BODY_CHARSET、Content-Type 头里的 charset、以及实际请求体字节流编码。Oracle 默认用数据库字符集（如 AL32UTF8），但 HTTP 服务端往往只认 UTF-8。
关键操作：
- 调用
UTL_HTTP.SET_BODY_CHARSET('UTF-8')（不是AL32UTF8） -
UTL_HTTP.SET_HEADER(req, 'Content-Type', 'application/json; charset=utf-8')—— 小写utf-8更稳妥 - 如果请求体来自
CLOB，确保它本身以 UTF-8 编码存储（DBMS_LOB.CONVERTTOBLOB可能需要介入） - 避免在字符串里硬拼
CHR(13) || CHR(10)模拟 HTTP 头，UTL_HTTP自动处理协议头，手动加反而破坏格式
超时和异常必须主动控制
UTL_HTTP 默认超时极长（可能达几分钟），且不抛标准异常。服务端卡住或 DNS 解析失败时，过程会长时间挂起，拖垮整个数据库会话。
必须显式设置：
-
UTL_HTTP.SET_TRANSFER_TIMEOUT(30)—— 单位秒，建议 10–30 秒之间 - 捕获
UTL_HTTP.END_OF_BODY、UTL_HTTP.TOO_MANY_REDIRECTS等特定异常，而不是只靠WHEN OTHERS - 调用
UTL_HTTP.END_RESPONSE(resp)放在EXCEPTION块末尾，否则连接不释放，很快耗尽HTTP_POOL连接数 - 对非
200响应码（如401、503）不要忽略，应记录resp.status_code和resp.reason_phrase
真正难搞的是 DNS 解析失败场景：ACL 允许 IP 但不允许域名时，UTL_HTTP.BEGIN_REQUEST 会直接报 ORA-29273: HTTP request failed，而错误堆栈里不带具体原因，得靠日志+抓包交叉验证。
