关键在于精准复刻原始运行环境，包括精确的os小版本、底层库版本、locale/时区、硬编码路径及/proc或网卡名依赖；docker价值是还原土壤而非仅轻量打包，须禁用浮动标签、离线安装旧依赖、绕过容器限制并验证三类运行时行为。
要让传统遗留微服务系统在现代基础设施上稳定运行，关键不是“让它跑起来”，而是“让它像当年一样跑”——包括精确的系统小版本、glibc/openssl/JDK 等底层库版本、locale 和时区设置、硬编码路径行为，甚至对 /proc 或网卡名（如 eth0）的依赖。Docker 的价值在于复刻原始运行土壤，而非仅做轻量打包。
精准锁定基础镜像，小版本不能错
很多崩溃源于系统级差异。例如某金融类微服务只在 CentOS 6.3 下全量验证通过，但使用 centos:6 标签拉取到的是 6.10，因 glibc 升级导致 GLIBC_2.14 not found 直接退出。
- 登录原生产服务器执行
cat /etc/redhat-release或lsb_release -a，确认发行版及**精确小版本号** - 优先选用 Docker Hub 官方历史 tag：
centos:6.3、ubuntu:14.04.6、debian:jessie - 禁用浮动标签：
latest、stable、centos:6等均不可靠，它们可能随时间指向不同快照
离线还原旧依赖，不依赖在线仓库
旧微服务常绑定已下线的组件：OpenSSL 1.0.2、JDK 6u45、Python 2.6.6、特定版本的 Oracle Instant Client 等。当前 apt/yum 源中早已无对应包，强行在线安装必失败。
- 在同版本旧系统中提前下载完整依赖树：
• Ubuntu/Debian：apt-get download libssl1.0.0=1.0.2g-1ubuntu4.20 python2.6=2.6.6-10ubuntu1
• RHEL/CentOS：yumdownloader --resolve --destdir ./pkgs openssl-1.0.2k-21.el7_9 java-1.6.0-openjdk-1.6.0.45-1.13.6.1.el7_1 - Dockerfile 中用
COPY pkgs/ /tmp/pkgs/+RUN rpm -ivh /tmp/pkgs/*.rpm（或dpkg -i）完成离线安装 - 对 C/C++ 类微服务，考虑用
musl-gcc静态编译核心二进制，彻底摆脱 glibc 版本绑定
绕过容器默认限制，模拟真实物理机行为
遗留微服务往往隐含“运行在裸机”的假设：校验系统时间偏移、读取 /proc/net/dev、硬编码 UID=500、绑定 eth0、依赖 /usr/lib/locale/zh_CN.GB18030 等——这些在默认容器中都会失效。
- 时间敏感服务：启动时加
--cap-add=SYS_TIME，并挂载宿主机时区：-v /etc/localtime:/etc/localtime:ro - UID/GID 写死：用
user: "500:500"启动容器；或在 Dockerfile 中RUN useradd -u 500 legacysvc - 路径与网络适配：
• 用VOLUME ["/opt/legacy/conf", "/var/log/legacy"]暴露目录，再通过-v复用原有配置与日志路径
• 若必须eth0，启动加--network=host（慎用），或在 entrypoint 中用ip link add eth0 type dummy模拟
验证三类关键行为，不止看“是否启动”
启动成功 ≠ 兼容。需重点验证以下三类运行时行为是否与原环境一致：
-
文件行为：创建含中文名的临时文件、读取 GBK 编码日志、访问
/proc/sys/kernel/shmmax等内核参数节点 -
网络行为：是否调用
getifaddrs()获取eth0地址、DNS 解析是否严格依赖/etc/resolv.conf原始内容、IPv6 是否被显式禁用 -
信号与生命周期：执行
docker kill -s SIGTERM后能否优雅关闭（而非立即kill -9）；某些老 Java 微服务需捕获 TERM 并转为kill -USR2触发 JVM 内部清理
