docker run --env-file 把值两边的引号传进了容器

把环境变量文件交给 docker run --env-file 后，程序可能读到 "/srv/app data"，连两侧的双引号也包含在路径里。密码或连接字符串同样可能多出引号，导致路径不存在、认证失败，而在本地 shell 中加载同一份文件却正常。

这里要确认的是变量的实际字符，而不只是应用报错。下面针对 Docker CLI 的 docker run --env-file 纯键值格式；Docker CLI 28.5.1 的解析器保留值中的引号，不做 shell 展开。不要把这条规则直接套到 docker compose、应用的 dotenv 库或面板的环境变量编辑器，它们可能使用不同语法。

文件里的引号不会自动消失

假设文件 docker.env 写成：

APP_LABEL="hello world"
APP_PATH=/srv/app data
APP_TOKEN=$TOKEN

传给容器的 APP_LABEL 包含两端的 "；APP_PATH 的值则是完整的 /srv/app data，空格不需要再用 shell 引号保护。APP_TOKEN 是字面量 $TOKEN，不会从宿主环境插值得到另一个值。

shell 在解析命令行时会去掉用于分组的引号，但环境文件不是 shell 命令行。给文件中的值加单引号，也不能让 Docker CLI 自动去掉它们。文件中的 # 只有作为注释行的标记时才被忽略；写在值后面通常也是值的一部分，不宜追加行尾说明。

先核对启动入口。如果实际运行的是 Compose，或镜像入口脚本自己再次读取文件，变量可能在另一层发生变化。应用日志中用 JSON 表示字符串时也会显示引号，因此不能只凭日志外观认定引号真的进入了变量。

用无敏感值的临时容器确认边界

在本机测试目录单独建立 probe.env，不要覆盖真实环境文件：

APP_LABEL="hello world"

下面的例子只输出这个测试变量。使用 Linux 容器模式，镜像不存在时 Docker 可能先拉取镜像：

docker run --rm --env-file ./probe.env busybox:1.36 \
  sh -c 'printf "<%s>\n" "$APP_LABEL"'

按上述解析规则，输出应是 <"hello world">。这里外面的尖括号是探针添加的边界，里面的双引号来自文件。将文件改成下面这样，再创建一个新的测试容器：

APP_LABEL=hello world

此时应得到 <hello world>。这个检查排除了真实应用的日志格式和配置二次解析，只验证指定 Docker 入口传递了什么。不要改成输出整个 env 或完整容器配置，它们可能包含其他凭据。

按启动入口保存环境文件

如果目标值本来就不包含引号，为 docker run 准备纯键值文件，例如：

APP_LABEL=hello world
APP_PATH=/srv/app data

只去掉承担 shell 分组用途的外围引号，保留值中真正需要的引号、空格和等号。不要用全局替换删除所有引号，也不要直接把共享 .env 改成这种写法：同一个文件若还被 shell source，其中未引用的空格会有不同意义。

两种入口确实需要不同格式时，保留各自文件，或者由可信配置源生成它们。不要为了“让 Docker 支持 shell 语法”而执行来源不明的环境文件；source 能执行命令，远不止读取变量。

如果值已经由受控 shell 正确设置并导出，也可通过变量名传递：

export APP_LABEL='hello world'
docker run --rm --env APP_LABEL busybox:1.36 \
  sh -c 'printf "<%s>\n" "$APP_LABEL"'

这次单引号属于 shell 命令语法。Docker CLI 读取导出的值，不再从文件取得这项配置。变量没有导出时不能依赖这种方式；实际服务还应避免同时从多个入口设置同名变量，让核对对象不明确。

修正文件后确认新容器与应用

环境文件在创建容器时读取。改完文件后仅重启已有容器，不会重新导入文件。正式服务应先保留旧文件和原启动配置，确认持久数据挂载，按已有部署流程替换容器；不要为了更新变量删除数据卷。

先用无敏感值的探针确认引号边界，再检查真实应用能否打开目标路径或建立连接。探针正常而应用仍失败时，继续检查应用自己的配置解析、路径存在性或凭据，不应再把所有错误归因于 Docker 引号。

需要回退时恢复上一份可用文件，并以原镜像、挂载和启动参数重新部署。若变量本来就要求字面引号，应恢复它们，不能把“所有值都不带引号”当作统一目标。