必须同时打通容器内权限、资源限制、内核参数和文件路径四层关卡：启动时用--ulimit core=-1设置无上限，加--cap-add=SYS_ADMIN或--privileged=true允许修改core_pattern，配置绝对路径如/var/log/core/core.%e.%p.%t并挂载宿主机目录持久化，最后用崩溃程序验证生成非零ELF core文件。
在Docker容器中启用CoreDump，不能只靠宿主机配置，必须同时打通容器内权限、资源限制、内核参数和文件路径四层关卡。缺一环，core文件就可能为空、找不到或根本不生成。
容器启动时放开ulimit限制
这是最基础也最容易遗漏的一步。Docker默认将core文件大小限制为0：
- 运行容器时显式设置：
docker run --ulimit core=-1:-1 ...（-1表示无上限） - 若用docker-compose，写成：
ulimits: { core: -1 } - 进容器后执行
ulimit -c，输出应为unlimited才生效
允许容器修改内核core_pattern
容器默认无权写/proc/sys/kernel/core_pattern，需赋予对应能力：
- 加
--cap-add=SYS_ADMIN（较重，但兼容性好） - 或更精准地用
--cap-add=SYS_PTRACE --cap-add=SYS_NICE（配合debug-init方案） - 若仍报错“Read-only file system”，说明需
--privileged=true（仅调试环境用，生产禁用） - 设置示例：
echo '/var/log/core/core.%e.%p.%t' > /proc/sys/kernel/core_pattern
确保目标目录可写且持久化
容器销毁即丢数据，core必须落盘到宿主机：
- 提前在宿主机创建目录并赋权：
mkdir -p /host/core && chmod 777 /host/core - 挂载进容器：
-v /host/core:/var/log/core:rw - 确认容器内该路径存在且可写：
touch /var/log/core/test && rm /var/log/core/test - 建议在
core_pattern中使用绝对路径，避免因工作目录不确定导致core丢失
验证与触发测试
别等真崩溃才检查——主动验证流程是否跑通：
- 在容器内运行一个会崩溃的程序（如
kill -SEGV 1，前提是PID 1进程可被信号终止） - 或用最小测试程序：
python3 -c "import ctypes; ctypes.string_at(0)" - 检查
/var/log/core/下是否有非零大小文件生成 - 用
file core.xxx确认是ELF core dump格式；用readelf -n core.xxx看是否含NT_PRSTATUS段（寄存器信息）
