关键是要提前配置内核core_pattern、ulimit限制和持久化挂载路径：使用--sysctl设置core_pattern、--ulimit core=-1放开限制，并通过-v挂载宿主机目录（chmod 1777确保可写），kubernetes中则用annotation配合卷挂载，同时验证信号类型与权限。
要让容器在异常退出时自动保留核心转储（core dump）文件，关键不是“等它退出后再补救”，而是提前配置好内核行为、资源限制和持久化路径，确保崩溃瞬间就能把内存快照写入安全位置。否则容器一退出，进程上下文消失，core 文件根本不会生成，更谈不上保留。
设置容器启动时的 core_pattern 和挂载目标目录
容器无法直接写入默认路径（如 / 或 /tmp），且多数镜像未启用 core dump。必须显式指定输出路径并确保可写：
- 使用
docker run --sysctl kernel.core_pattern=/dump/core.%e.%p将转储路径设为/dump/（注意：该路径需与后续挂载点一致） - 通过
-v /host/dump:/dump:shared挂载宿主机目录，宿主机上提前执行mkdir -p /host/dump && chmod 1777 /host/dump（1777 是必须的，否则非 root 进程无法写入） - 若用 Kubernetes，可通过 Pod annotation 设置：
k8s.ksyun.com/kci-core-pattern: "/tmp/cores/core.%h.%e.%p.%t"，同时挂载 NFS/CSI 卷到/tmp/cores
放开 ulimit 并确保主进程继承该限制
默认 ulimit -c 是 0，即禁用 core dump。仅在容器内执行 ulimit -c unlimited 不可靠——它可能被 ENTRYPOINT 覆盖或不传递给子进程：
- 启动时加
--ulimit core=-1（-1 表示 unlimited），这是 Docker 原生支持的方式，比在 Dockerfile 中 RUN ulimit 更稳定 - 避免在 shell 启动脚本中用
ulimit，尤其当主进程是 exec 方式启动（如exec "$@"）时，shell 的 ulimit 不会继承 - 验证是否生效：进入运行中容器执行
ulimit -c，应返回unlimited或一个正整数
确认程序触发的是可生成 core 的信号
不是所有终止都会产生 core 文件。只有收到带 CORE 动作的信号（如 SIGSEGV、SIGABRT、SIGQUIT）才会触发转储；SIGKILL（如 OOMKilled）或 SIGTERM 不会。
- 测试方法：在容器内运行一个故意段错误的程序（如
kill -SEGV $(pidof yourapp)），再检查/dump/是否出现core.*文件 - 若应用是 Go（含 cgo）、C/C++ 或 Rust，通常天然支持；Python/Node.js 需额外配置（如 Python 启动时加
faulthandler.enable()或用gdb --args python app.py） - 注意：systemd 环境下（如某些基础镜像）可能由
systemd-coredump接管，此时需检查其配置是否允许外部路径
容器退出后快速验证与提取 core 文件
即使配置正确，也要确认文件真实落盘且未被清理：
- 容器 Exited 后立即执行
docker ps -a | grep Exited，记下容器 ID - 不要删容器！用
docker commit <id> debug-img</id>保存当前状态，再docker run -it --rm -v $(pwd)/dumps:/dumps debug-img ls -l /dump/查看 core 是否存在 - 若 core 已生成但体积为 0，常见原因是权限不足（宿主机目录非 1777）或路径不存在（
/dump在容器内未创建）；可在 ENTRYPOINT 开头加mkdir -p /dump 2>/dev/null || true防御
