装包时刷出一屏 debconf: unable to initialize frontend。同一段输出里还跟着 26 not upgraded、报错里多出来的 .so、my.cnf 里的 host-cache-size=0。
这四个看着都像出事了。四个都是正常的。
它们有个共同点：都出现在你正在做对的事的时候。你在装包、在启动服务、在看报错，全是关键动作。一看到异常字样就停下来查，一查半小时，最后发现什么都没坏。
这半小时没花在解决问题上。它花在读错回显上。
先交代这台机器。1Panel v2 起的环境，PHP 8.4.25 容器 1panel-php-fpm:8.4.25。MySQL 8.4.11 容器 mysql:8.4.11，容器基础镜像 Debian 13（trixie）。宿主机 Ubuntu，服务器 4 核 8G。回显全部来自 2026-09-16 和 09-17 这两天，数值和文本原样保留。
下面两个变量换成你在 1Panel 里给对应容器起的名字：
bash
# 换成你在 1Panel 里给对应运行环境起的名字（= 容器名）
export PHP_CTN="php84"
export MYSQL_CTN="mysql84"一屏 debconf 降级
在容器里装 unzip，终端刷出这么一片（2026-09-17 实测）：
vbnet
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
debconf: unable to initialize frontend: Teletype
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Noninteractive四个 unable to initialize，一个 falling back 接一个 falling back。第一次见会以为安装过程坏了。
没有。这是 debconf 在找交互前端，一个都没找到，降级到 Noninteractive 装完了。
debconf 是 Debian 的包配置交互系统。装包时它可能需要问你问题，比如检测到配置文件被修改要不要覆盖。于是它按优先级依次试几种前端：Dialog、Readline、Teletype、Noninteractive。
Dialog 要 TTY 加 TERM 环境变量，Readline 要控制终端，Teletype 也要控制终端。Noninteractive 什么都不需要，全部用默认值。
docker exec -i 不分配 TTY，要 TTY 得加 -t。所以前三种依次初始化失败，debconf 最终降级到 Noninteractive。
这正是你想要的：无人工干预，全部按默认值装完。
回显自己把原因写出来了，只是太啰嗦容易被略过。(TERM is not set, so the dialog frontend is not usable.) 说的是环境里没有 TERM。(This frontend requires a controlling tty.) 说的是没有控制终端。
怎么确认它真的无害？看结果行。我当时盯的就是这一行。这片 debconf 信息之后紧跟着：
java
Setting up unzip (6.0-29+deb13u1) ...顺序永远是 debconf 降级信息在前，包安装成功信息在后。只要 Setting up <包名> 出现、后面没有 E: 开头的错误，就是装好了。
嫌它吵就给 docker exec 设一个环境变量，不依赖 TTY，任何环境都能用：
bash
docker exec -i "$PHP_CTN" bash -lc '
export DEBIAN_FRONTEND=noninteractive # 直接指定前端，跳过三次失败尝试
apt-get install -y --no-install-recommends unzip
'这条是通用做法，我自己这次没用。刷屏本身不影响结果，值不值得改看你嫌不嫌烦。
26 个包没升级
同一段安装输出里（2026-09-17 实测）：
arduino
0 upgraded, 1 newly installed, 0 to remove and 26 not upgraded.
Need to get 173 kB of archives.
After this operation, 396 kB of additional disk space will be used.26 not upgraded，26 个包没升级，看着像批量升级失败。
这是 apt 的动作统计行，格式是 <动作> <数量>。逐个读。0 upgraded 是本次升级了 0 个，1 newly installed 是本次新装了 1 个，就是 unzip。0 to remove 是本次卸载 0 个。26 not upgraded 是仓库里还有 26 个包存在可用更新，本次操作不涉及。
没升级不算失败，是你没让它升。你只装了 unzip，apt 就只处理 unzip 这一个包的事，顺带告诉你另外还有 26 个包有新版本。
想升它们，得显式执行 apt-get upgrade。
这句无害提示背后藏着一个真陷阱
容器内不要跑全量 apt-get upgrade。
容器镜像里的包版本是成组锁定的。镜像构建时，php-fpm 二进制、各扩展的 .so、它们依赖的共享库，都是在同一个版本组合下编译出来的。
在容器里跑一次全量 upgrade，它会替换掉一批共享库，但不会重建镜像，也不会重新编译那些扩展 .so。结果可能是依赖库升上去了、.so 还是按旧版本编的，原本能加载的扩展反而加载失败。
我的做法是：在 PHP 容器里只 apt-get install 具体需要的包，从不 upgrade。宿主机的系统包该升就升，那是另一回事。容器内的包版本跟着镜像走，不由你手动维护。
报错里多出来的那个 .so
四个扩展加载失败时，PHP 报的 Warning 长这样（2026-09-16 实测）：
csharp
PHP Warning: PHP Startup: Unable to load dynamic library 'gd' (tried: .../gd.so (libpng16.so.16: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: .../intl.so (libicuio.so.76: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library 'zip' (tried: .../zip.so (libzip.so.5: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library 'memcached.so' (tried: .../memcached.so (libmemcached.so.11: cannot open shared object file: No such file or directory)) in Unknown on line 0四条并列起来看，前三条的模块名是 'gd'、'intl'、'zip'。第四条是 'memcached.so'，多了一个 .so。
PHP 报的是你在配置里写的那个名字。名字上带着 .so，说明 php.ini 或 conf.d 里的扩展 ini 写的是：
ini
; 第四条的写法
extension=memcached.so前三条是这么写的：
ini
; 前三条的写法
extension=gd
extension=intl
extension=zip两种写法 PHP 都能处理，它会识别后缀并补全。所以第四条实际去找的文件是 .../memcached.so，没变成 .so.so。功能上的差别只有一个：名字里带不带 .so，取决于你写没写。
那为什么值得单独提？配置写法不统一本身就是隐患。当你要批量处理这些 ini，脚本化开关某个扩展、批量替换扩展名，多一个后缀就多一种要匹配的情况。建议统一成不带后缀的写法：
ini
; 推荐：不带后缀
extension=memcached
; 兼容但不必再用
extension=memcached.so顺带一个实用点：报错里的模块名，就是你该去 conf.d 里找的那个文件名，docker-php-ext-<名字>.ini。上面第三条报 'zip'，对应的就是 docker-php-ext-zip.ini。
还有一处得订正。我自己的部署记录里，对这条差异的判读写成过「出现了 memcached.so.so 双后缀尝试」。但原始回显里并没有 .so.so，只有 tried: .../memcached.so。这里按原始回显的可见差异重新表述：四条 Warning 里只有一条的模块名带后缀。记录里那句话需要订正。
my.cnf 里的 host-cache-size=0
1Panel 创建 MySQL 时，往 my.cnf 里默认写进了一个参数：
ini
host-cache-size=0host_cache 是 MySQL 用来缓存客户端主机名解析结果的结构。看到 =0，本能反应是某个缓存被彻底关掉了，会不会影响性能。
记录里的实测结论：MySQL 8.4.11 带这个参数可以正常启动并服务查询。docker restart 之后 SELECT VERSION() 正常返回 8.4.11。
它不是故障信号，可以直接保留。
关键是别把它和真正的性能参数混淆。这一组参数里，真正决定 MySQL 在新机器上跑得快不快的是 innodb_buffer_pool_size。那是另一个话题，也是这次部署里唯一一个必须手动给的内存参数。my.cnf 里那一堆内存相关项，其余几个都已经是 8.4 的默认值了。【待补：这次 innodb_buffer_pool_size 实际给了多少，底稿未写】
读回显的两步
把四个案例抽出来，共性只有一句：它们的位置都在正常流程里，只是文本里带了异常字样。
所以读回显的正确姿势是两步。
先找结果行。Setting up xxx、SELECT VERSION() 的返回值、Started、RUNNING。结果行对了，基本就没事。
再回看警告。这时候警告要么是噪音，要么是解释为什么是这个结果的背景信息。比如 debconf 那三行降级，就是在解释为什么后面能无交互装完。
反过来，结果行不对，那些警告才是真正的线索，那就该上排查工具了。
结果行在哪，是我看回显时第一个找的东西。