Docker 交互容器第一次按 Ctrl-P 无法调出历史命令

在 docker run -it 打开的 Bash 中，上方向键能正常调出上一条命令，第一次按 Ctrl-P 却没有反应，再按一次又像跳过了一条历史记录。若同一个终端在宿主机上正常，需要检查 Docker 的脱离按键，而不必先清空 Bash 历史或重装终端。

Docker 默认用依次按下 Ctrl-P、Ctrl-Q 的序列脱离交互连接。Ctrl-P 恰好也是常见命令行编辑模式中的上一条历史快捷键：Docker CLI 先等待序列是否完成，应用不能立即按普通历史键处理它。本文针对支持 --detach-keys 的 Docker CLI 交互连接，不把所有 Ctrl-N、方向键或终端输入故障都归为这个原因。

为当前命令换一组脱离按键

先在独立交互容器中验证，避免改动正在处理任务的服务。以下示例不挂载业务数据；容器名若已存在，换一个新名字：

docker run -it --name history-key-check --detach-keys="ctrl-^,q" ubuntu:24.04 bash

进入 Bash 后，执行两条无副作用的命令：

printf 'first\n'
printf 'second\n'

随后按一次 Ctrl-P。若原来确实被 Docker 的默认脱离序列截获，现在应能立即调出上一条命令；Ctrl-N 则按 Bash 当前的行编辑模式向后移动。这里检验的是输入路径，不要求改动容器内的 Bash 配置。

新的脱离方式是先按 Ctrl-^，松开后再按普通字母 q，不是 Ctrl-Q。选择前确认终端或应用没有占用这组按键；它只是示例，不能保证适合所有终端。脱离后容器继续运行，不等于停止或删除容器。

若要重新连接同一测试容器，明确给 attach 也传入相同设置：

docker attach --detach-keys="ctrl-^,q" history-key-check

这样不依赖后续连接是否继承先前命令的选择。attach 连接的是原容器入口进程的输入输出，不会新建另一个 Bash。正在使用业务进程时，不要把输入测试命令随意发给它。

只有默认序列冲突时才改 Docker 设置

如果换键后 Ctrl-P 仍无反应，检查宿主终端是否截获它、Bash 是否处于预期的行编辑模式，以及其他输入键能否正常到达应用。上方向键与 Ctrl-P 的表现可以提供线索，但单个现象不足以排除终端映射等其他问题。

这项处理也不针对未分配交互 TTY 的后台服务。没有按 -i、-t 建立相应输入与终端条件时，不能靠更改脱离键就得到同样的交互行为。不要为修历史键顺手改变生产服务的 TTY 配置。

需要固定习惯时再修改客户端配置

验证单次命令有效后，可以在 Docker CLI 使用的 config.json 中设置 detachKeys。默认配置位置是 ~/.docker/config.json，但应同时检查当前是否使用了其他客户端配置目录。

需要合并的 JSON 字段是：

{
  "detachKeys": "ctrl-^,q"
}

这段只展示相关字段，不能用它覆盖已有配置文件。保留其他设置和凭据配置，修改前备份原文件并确认 JSON 格式有效；不要把整个文件内容贴到公共日志中。

这是客户端的按键设置，不是 Docker daemon 的配置，无需为此重启服务端。它会影响使用该配置的后续客户端操作，单次 --detach-keys 参数可以覆盖默认值。不要由此推断其他终端工具或 Compose 的每一种连接方式都会采用相同规则。

验收脱离与回退

确认历史键恢复后，还要试一次新的脱离序列，并在另一终端查看测试容器是否仍在运行。随后重新 attach，确认仍连接到原来的 Bash 会话。不要用 Ctrl-C 或 exit 代替脱离验证：前者可能向前台进程发送中断，后者会退出这个 Bash；当它是容器主进程时，容器也随之结束。

只用了命令行参数时，下一次连接恢复原参数即可回退。改过 detachKeys 时，恢复原字段或原配置文件，再新建客户端连接验证。这个调整不会清除命令历史，也不会撤销会话中已经执行的命令；测试容器确认不再需要后，按原有清理流程处理。