改了.env却没生效：怎样核对网关容器环境变量的实际优先级

改了.env不代表容器环境会跟着变化。.env可以参与Compose插值，env_file用于向容器提供环境，environment又可能覆盖同名值。本文用不同的假哨兵追踪最终值来源，当前仅完成有限来源矩阵和静态配置检查，没有执行Compose渲染或重建容器。

先区分插值来源与容器值来源

附件分别为镜像默认、env_file、environment和命令行覆盖填入不同值。四轮按顺序增加来源，参考最终值依次为image-fake、envfile-fake、environment-fake、cli-fake。这里environment是明确写在服务里的直接字面值，没有混入嵌套插值，便于隔离覆盖问题。

宿主shell和.env影响插值时，只有配置实际引用或传入相应变量，才会进入容器环境。不能把“.env里有MODE”解释成“每个容器自动拥有MODE”。Docker官方优先级表还区分插值得到的environment或env_file值等情况，实际完整规则应按当前Compose版本核对；附件四层参考不冒充完整实现。

空串与未设置必须分开保留

environment显式设为空，可能是有意覆盖env_file中的非空值，不应被自作聪明地当成“没有配置”再回退。未设置则需要按实际语法决定继承或移除。审计记录应写来源、是否存在和长度，而不是只比较最终掩码；两份掩码相同可能只是都显示几个星号。

未来复现时，先用全假值执行docker compose config，核对最终模型；再只在独立假容器里读取目标变量，确认注入阶段。不要用生产容器的全量env输出作为排查材料，它可能包含无关凭证。镜像默认值也需来自真实inspect或构建文件，只看到旧笔记里一行ENV不足以证明当前镜像相同。

为每次实验保存来源矩阵

可把每轮启用来源、配置文件摘要、Compose版本和最终假值写在一张表。只改一个来源，再观察最后由哪层决定；若一次同时修改shell、env_file和服务配置，结果即使变化也难以解释。应用启动后还可能有自己的配置文件覆盖环境，那里属于下一层，应另记最终读取结果。

本运行器按明确的四层参考顺序选择假值，并实际读取c029.compose.yaml和c029.env，检查env_file路径、直接environment哨兵及env文件值对应。它只做限定文本断言，不验证完整YAML语义，不会启动未拉取的示例镜像。输出reference_final_values没有声称是Docker真实返回。本文与美元符号插值教程的边界在于：前者检查字符是否被解释，本篇检查同一变量究竟来自哪里。先用来源追踪确定正在改的是有效层，再核对字符，能减少反复编辑一份根本没有决定最终值的文件。

配套样本与复核入口

下载本篇独立合成输入和实验运行器，并下载运行器实际读取的c029.compose.yaml、c029.env。上述文件放在同一目录后运行 python run_lab.py C029。完整运行需要全部四十四份输入及相关配置。结果中的method区分离线计算、静态参考检查与回环实测，不能把前两者当成真实网关已通过。

补充文件：c029-dot.env、c029-shell.ps1。合成表供独立复算，配置片段是否实跑以正文说明为准。

资料核对日期：2026-10-24。官方依据1；官方依据2。

与本站相关基础教程的区别：旧文列出环境变量名；本文只做shell/.env/env_file/environment间来源优先级对照，与美元符号插值篇的字符保真任务不同。