PMA_HOSTS仅控制登录页下拉列表显示，不改变连接逻辑，每个服务器仍需DNS可解析、网络可达、权限合法；它不能替代PMA_HOST的启动绑定作用，也不能表达端口/SSL等差异配置，复杂场景必须挂载config.user.inc.php精确控制。
phpMyAdmin容器中用PMA_HOSTS预设多个服务器
在 docker 环境下，pma_hosts 是唯一能通过环境变量批量注入可信服务器列表的方式。它不改变连接逻辑，只控制登录页下拉菜单的显示项——每个列表项背后仍需独立可连、网络可达、权限合法。
常见错误是以为填了 PMA_HOSTS=db,prod-db,backup-db 就自动能连，结果点选后报 mysqli::real_connect(): (HY000/2002): Connection refused。根本原因是：容器 DNS 解析不到 prod-db，或目标 DB 没开放该容器所在子网的访问权限。
-
PMA_HOSTS值必须是逗号分隔的主机名（不能带端口），且这些名字要能被 phpMyAdmin 容器的 DNS 正确解析（比如 Docker Compose 默认桥接网络中，服务名就是 DNS 名） - 对应每个主机，需额外用
PMA_VERBOSES提供友好名称（如开发库,生产库,备份库），否则下拉里只显示原始 host 字符串 - 端口不能通过环境变量统一指定；若各服务器端口不同，必须改用挂载
config.user.inc.php手动配置每个$cfg['Servers'][$i]['port'] - 所有目标 MySQL 必须已配置允许远程连接（
bind-address = 0.0.0.0）、用户授权包含该容器 IP 段（如'pma'@'172.18.0.%'）
为什么PMA_HOST不能动态切换，而PMA_HOSTS又不能替代它
PMA_HOST 是启动时硬绑定的 fallback 连接目标：当登录页没选服务器、或 AllowArbitraryServer 关闭时，phpMyAdmin 会直接连它。而 PMA_HOSTS 只是菜单数据源，不参与连接决策——它甚至不会触发任何网络探测，纯前端渲染。
典型误用场景：把 PMA_HOST=local-db 和 PMA_HOSTS=local-db,cloud-db 一起设，以为能“默认连本地、手动选云端”。结果发现选了 cloud-db 后仍连本地——因为没开 AllowArbitraryServer，phpMyAdmin 根本不读你选的下拉值，强制走 PMA_HOST。
- 容器启动后
PMA_HOST即固化，无法运行时修改；想切目标，要么重启容器改环境变量，要么启用AllowArbitraryServer -
PMA_HOSTS列表里的服务器，只有在AllowArbitraryServer = true或用户主动选择时才真正发起连接，否则只是静态选项 - 安全策略上，
PMA_HOST是白名单内最可信的一个；PMA_HOSTS是次级白名单，但仍要求每个条目都预先审查过网络与权限
挂载config.user.inc.php比纯环境变量更可靠
当服务器数量多、端口/认证方式/SSL 设置不一致时，仅靠 PMA_HOSTS + PMA_VERBOSES 无法表达完整配置。此时必须挂载自定义 PHP 配置文件，用代码逻辑控制每个服务器的细节。
立即学习“PHP免费学习笔记（深入）”；
例如云端 DB 要求 SSL 连接、本地 DB 用 socket、测试库走非标端口——这些差异无法用环境变量描述，硬塞进 PMA_HOSTS 会导致部分条目不可用或连接失败。
- 挂载路径必须是
/etc/phpmyadmin/config.user.inc.php（官方镜像约定路径），内容需以<?php开头，结尾不加?> - 每个服务器必须使用从 1 开始的连续整数索引：
$cfg['Servers'][1]、$cfg['Servers'][2]，跳号或重复索引会导致后续配置被忽略 - 务必显式设置
$cfg['Servers'][$i]['host']、$cfg['Servers'][$i]['port']、$cfg['Servers'][$i]['user']，不要依赖环境变量 fallback - Docker Compose 中挂载示例：
volumes: - ./config.user.inc.php:/etc/phpmyadmin/config.user.inc.php:ro
AllowArbitraryServer开启后必须限制访问范围
启用 $cfg['AllowArbitraryServer'] = true 后，登录页会出现 Server hostname: 输入框，用户可任意填写 MySQL 地址。这功能本质是关闭了服务端校验，把风险交给了网络层和管理员。
线上环境一旦暴露此入口，攻击者可批量探测内网 MySQL、撞库、甚至利用弱密码直连生产库。不是“开了就能用”，而是“开了就必须配好边界”。
- 只应在内网开发机或 CI 测试节点启用，禁止在公网可访问的实例上打开
- 必须配合反向代理做 IP 白名单（如 Nginx 的
allow 192.168.1.0/24; deny all;） - 目标数据库的 MySQL 用户授权必须严格限定来源 IP，避免
'root'@'%'这类宽泛授权 - phpMyAdmin 容器自身需配置出网策略，比如 Docker network driver 设为
bridge并确认iptables未拦截其 outbound 流量
实际混用多个环境时，最稳的组合是：PMA_HOSTS + 挂载 config.user.inc.php + 内网访问限制。环境变量负责快速枚举，PHP 配置负责精确控制，网络策略兜底安全——三者缺一不可。
