根本原因是Docker容器内缺失时区定义文件及有效软链接，导致Oracle客户端（如.NET驱动）初始化时区解析失败，报ORA-01882；须同时配置TZ环境变量、正确建立/etc/localtime软链接并确保/usr/share/zoneinfo/Asia/Shanghai存在。
根本原因不是网络不通，而是容器内缺失时区信息导致 oracle 客户端初始化失败 —— 报错 ora-01882: timezone region not found 就是典型信号。
为什么 ORA-01882 会在 Docker 容器里高频出现
Oracle .NET 驱动（如 Oracle.ManagedDataAccess 或 SqlSugar 的 Oracle 支持）在连接建立初期会调用系统时区数据库做解析。Alpine 或 slim 版本的 .NET 基础镜像（如 mcr.microsoft.com/dotnet/aspnet:6.0-alpine）默认不带 /usr/share/zoneinfo，或者 /etc/localtime 指向一个空链接或不存在路径，导致驱动找不到 Asia/Shanghai 这类区域名。
- 错误不会出现在本地开发环境（Windows/macOS 自带完整时区库）
- 也不会在容器里执行
date命令时报错 —— 它只影响 Oracle 驱动的内部时区解析逻辑 - 即使你手动设了
TZ=Asia/Shanghai环境变量，若底层/usr/share/zoneinfo/Asia/Shanghai文件不存在，照样报错
必须同时满足的两个条件才能修复
光设环境变量不够，光拷贝时区文件也不够 —— 必须让容器同时具备「时区定义文件」和「正确的软链接指向」。
- 在
Dockerfile中添加两行（顺序不能反）：ENV TZ=Asia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
- 如果基础镜像是 Alpine，需额外安装 tzdata：
RUN apk add --no-cache tzdata
- 不要依赖
-e TZ=Asia/Shanghai启动参数 —— 它只设环境变量，不修复文件系统层面缺失
验证是否真正修复
进容器后运行这几条命令，结果必须全部符合预期：
-
ls -l /etc/localtime→ 应指向/usr/share/zoneinfo/Asia/Shanghai -
cat /etc/timezone→ 输出应为Asia/Shanghai -
find /usr/share/zoneinfo/Asia -name "Shanghai"→ 应有输出 - 再启动应用，
ORA-01882消失，连接可建联
容易被忽略的是：很多团队只改了 TZ 环境变量就以为搞定了，但没检查 /etc/localtime 是否真实生效 —— 这个软链接一旦断开，Oracle 驱动照样找不到时区。
