必须安装并启用yum-plugin-priorities插件，因为CentOS 7默认不支持priority参数，该插件是唯一使priority=N配置生效的机制；未安装时，yum会无序尝试所有启用源，导致包冲突或安装非预期版本。
为什么必须配 yum-plugin-priorities 才能生效
CentOS 7默认情况下不会启动仓库优先级控制，yum会随意地依次尝试所有已启用的源。这就可能导致冲突包（比如版本或签名不同但同名的python3或openssl）从质量较低的源进行安装。只有安装了yum-plugin-priorities并将其启用后，priority=参数才会生效。
常见错误现象：yum install 报 Package conflicts 或安装了旧版包；yum repolist 显示多个源都 enabled，但实际没走预期源。
- 先确认插件是否已装：
yum list installed | grep priorities - 没装就运行：
yum install -y yum-plugin-priorities - 检查插件是否启用：
cat /etc/yum/pluginconf.d/priorities.conf，确保[main]下有enabled=1 - 若为
0，手动改写为1并保存
priority= 数值设多少才合理
数值越小优先级越高，但不能全设成 1 —— 否则等于没设。关键是要拉开差距，且基础源必须压倒扩展源。
典型配置逻辑：
base、updates、extras这些最新核心仓库：统一设priority=1- EPEL 源（如清华或阿里 EPEL）：设
priority=2或3，避免覆盖系统关键包 - 第三方源（Docker、Kubernetes、私有源）：设
priority=10起，明确降级 - 本地源（
file:///mnt/cdrom）：可设priority=1，但必须确保其内容完整且 GPG 可信，否则会卡住安装
注意：priority 是 per-repo 的，必须写在每个 [repo-id] 小节里，不能只写在文件开头。
修改后为什么 yum makecache 还是走错源
缓存重建不等于优先级重载 —— yum makecache 只刷新元数据，但不会重新评估仓库顺序。真正生效要靠 yum 运行时按 priority 排序匹配。
验证方式不是看缓存速度，而是看具体命令行为：
- 运行
yum --showduplicates list python3 | head -10，观察包来源列（from字段）是否为你设的高优源 - 执行
yum install -y httpd时加-v参数：yum -v install httpd，输出里会显示 “using repo: base” 或类似提示 - 查当前活动源：
yum repolist enabled，结果末尾应带priority列（需 yum 3.4.3+ 支持）
如果仍走错，大概率是某个 repo 文件漏写了 priority=，或拼写错误（比如写成 priotity），或该 repo 的 enabled=0 被意外关闭。
混用阿里云 Base 源 + 清华 EPEL 源时的坑
阿里云和清华各自维护独立的 EPEL 镜像，但它们的 epel-release 包版本可能不一致。直接混用会导致 yum update 升级时因签名冲突失败。
正确做法：
- Base 和 Updates 用阿里云：
baseurl=https://mirrors.aliyun.com/centos/7/os/$basearch/ - EPEL 必须用清华源，且用清华提供的
epel-release包：rpm -Uvh https://mirrors.tuna.tsinghua.edu.cn/epel/epel-release-latest-7.noarch.rpm - 不要用
yum install epel-release—— 它默认装的是最新源的包，GPG key 不匹配清华镜像 - 编辑
/etc/yum.repos.d/epel.repo，确认gpgkey指向清华：https://mirrors.tuna.tsinghua.edu.cn/epel/RPM-GPG-KEY-EPEL-7
优先级数字本身不解决签名问题，但错误的 GPG key 会让整个 repo 被 yum 拒绝加载，此时 priority 再低也没意义。
priority=1 就只是注释。 
