--oom-score-adj用于控制容器在内存超限时被OOM Killer杀死的优先级，数值越低越靠后被杀，但必须配合--memory才生效；-500适用于核心服务，+300～+500用于临时任务，-1000需特权且慎用。
直接用 --oom-score-adj 控制容器在内存极载时被内核 OOM Killer 杀死的先后顺序，数值越低越靠后被杀，但必须搭配 --memory 才真正生效。
必须配内存限制，否则参数无效
OOM Killer 只在容器内存使用超出 --memory 设定值时才启动评估。没这个硬边界，内核不会对单个容器做 OOM 判定，--oom-score-adj 就完全不参与决策。
- 只设
--oom-score-adj=-500不设--memory：参数被忽略，容器可能和宿主机其他进程一起被随机杀死 - 正确组合示例：
--memory=1g --oom-score-adj=-500，此时该容器在超限时有更高生存权重 - 若同时启用 swap，建议显式设
--memory-swap=1g（即禁用 swap），避免延迟触发 OOM
常用取值与对应角色
数值范围是 -1000 到 +1000，0 是默认值，代表和宿主机普通进程同等优先级。
- -500：推荐用于数据库、核心 API 等关键服务，显著降低被终止概率
- 0：默认，适用于常规业务容器，无额外保护
- +300～+500：适合日志采集、定时导出等临时任务，内存紧张时优先让出资源
-
-1000：完全豁免 OOM Killer，仅限特权容器（
--privileged）且需内核支持CONFIG_OOM_DISABLE，生产环境慎用
验证是否生效
容器启动后，进入容器检查主进程（PID 1）的评分值：
- 执行：
docker exec 容器名 cat /proc/1/oom_score_adj - 应返回你设定的值（如 -500）；若返回 0 或其他值，常见原因是 Docker 版本低于 20.10，或漏配
--memory - 注意：cgroup v2 环境下该路径可能不可见，此时应确保使用 Docker 20.10+ 并依赖启动参数而非手动写入
别和 --oom-kill-disable 混用
--oom-kill-disable 是全局禁用 OOM Killer，风险极高：
- 一旦容器内存失控，可能耗尽宿主机全部内存，拖垮整个系统
- 它不区分容器重要性，是“一刀切”，无法实现分级牺牲
- 生产环境应始终保留 OOM Killer，靠
--oom-score-adj + --memory实现可控的优先级调度
