优先使用现成官方镜像，避免自行构建；若必须构建，需严格校验安装包完整性、配置ulimit限制、确保目录权限为777且用绝对路径，并正确匹配-s/-e参数与安装包类型。
能直接用现成镜像就别自己构建，除非你明确需要定制版或企业合规要求必须从源码可控构建。官方 docker-images 仓库提供的构建脚本虽完整，但耗时长、依赖多、失败点分散，新手容易卡在权限、路径、资源限制等环节。
buildContainerImage.sh 脚本执行前必须确认的三件事
这个脚本不是“扔进目录就跑”，它对环境有隐式强依赖：
- 当前用户必须对
dockerfiles/19.3.0/目录有读写权限，且不能是 root 切换来的普通用户（常见于 su - oracle 后执行失败） -
LINUX.X64_193000_db_home.zip必须完整解压前校验 SHA256，官方镜像构建过程不校验包完整性，损坏包会导致createDB.sh在 54%–77% 阶段静默退出，日志里只留Aborted (core dumped) - 宿主机 ulimit 设置必须提前生效：
nofile=262144:262144和nproc=16384:16384要写入/etc/security/limits.conf并重新登录终端，否则构建中途会因 file descriptor 不足失败
运行容器时 -v 挂载路径权限必须是 777，且不能用相对路径
Oracle 容器启动时由 oracle 用户初始化数据库，该用户对挂载目录没有 sudo 权限。若用 chmod 755 或未授权，你会看到：
mkdir: cannot create directory ‘/opt/oracle/oradata’: Permission denied
同时，-v 参数中的宿主机路径必须是绝对路径，比如 /mydata/oracle/oradata，写成 ./oradata 或 ~/oradata 会导致挂载失败且无明确报错，只在 docker logs oracle19c 里出现 cat: /opt/oracle/cfgtoollogs/dbca/ORCL.log: No such file or directory
正确做法：
sudo mkdir -p /mydata/oracle/oradata && sudo chmod 777 /mydata/oracle/oradata
ORACLE_PWD 环境变量值不能含特殊字符
很多教程示例用 ORACLE_PWD=oracle123! 这类带感叹号的密码，会导致容器启动后数据库创建失败，日志中出现：
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
ERROR: Password must contain at least one lowercase letter, one uppercase letter, one digit, and one special character
但实际错误根源是 shell 解析 ! 为历史命令扩展符，传入容器的密码被截断。安全又兼容的做法是：
- 用字母+数字组合，如
ORACLE_PWD=Orcl2026 - 避免
! @ $ % ^ & * ( ) ` " ' \ | ; : , . ? /中任意字符 - 如果必须用特殊字符，整个值用单引号包裹：
-e 'ORACLE_PWD=oracle@2026'
镜像构建完成但 docker images 看不到？检查 buildContainerImage.sh 的 -s/-e/-x 参数是否匹配安装包版本
脚本默认按 -e（企业版）构建，但你放的是标准版安装包 LINUX.X64_193000_db_home.zip，就会构建出一个空镜像层，docker images 列表里 ID 是 <none>，大小为 0B。必须显式指定：
./buildContainerImage.sh -v 19.3.0 -s —— 对应标准版2
./buildContainerImage.sh -v 19.3.0 -e —— 对应企业版
参数和安装包类型不一致时，脚本不会报错，只会跳过关键步骤，这是最隐蔽也最容易复现的坑。
