环境变量不自动跨服务共享，必须通过统一配置中心（如nacos、spring cloud config）或编排工具（k8s configmap、docker compose env_file）集中注入，实现多服务配置复用；java服务可通过@value读取，k8s支持envfrom批量注入，docker镜像构建时注入适用于静态配置，运行时代理服务则适配混合架构。
环境变量本身不自动跨服务共享，必须通过外部机制统一注入或集中管理，才能实现多服务间配置参数的复用。
统一配置中心驱动环境变量
把配置从各服务本地剥离，交由专用配置中心（如Nacos、Apollo、Consul或Spring Cloud Config）统一托管。服务启动时主动拉取配置，并将其映射为运行时环境变量。
- 例如：Java服务通过
@Value("${db.url}")读取配置中心下发的值，等效于设置了DB_URL环境变量 - Docker Compose中可配合
env_file或environment字段，从配置中心API动态生成.env文件再注入 - Kubernetes中常用ConfigMap + downward API或initContainer预加载，使Pod内所有容器共享同一组环境变量
容器编排层统一注入
在部署阶段由编排工具统一分发环境变量，避免每个服务单独维护。
- Docker Swarm使用
docker config创建加密配置，通过--config挂载到服务，再由应用读取并转为环境变量 - K8s中用Secret/ConfigMap以
envFrom方式批量注入，一个ConfigMap可被多个Deployment引用，修改后滚动更新即生效 - 注意：K8s中
envFrom注入的变量名必须符合DNS-1123规范（小写字母、数字、连字符），否则会被跳过
构建时注入 + 镜像标准化
适用于配置相对稳定、变更频率低的场景。在CI/CD流水线中，根据部署环境（dev/staging/prod）预先注入环境变量，打包进镜像。
- 用Docker BuildKit的
--build-arg传参，在Dockerfile中用ENV固化 - 镜像基础层统一定义通用变量（如
TIME_ZONE=Asia/Shanghai），上层服务镜像只覆盖业务相关变量 - 缺点是配置变更需重建镜像，不适合动态调整的敏感参数（如密码、密钥）
运行时配置代理服务
部署一个轻量级配置代理（如Confd、Envoy + xDS或自研HTTP配置网关），所有服务启动时向其发起一次HTTP请求获取当前环境变量集合，并写入进程环境。
- 代理可监听ZooKeeper/Kafka事件，配置变更实时推送给已注册的服务
- 适合混合架构（容器+虚拟机+物理机共存），不依赖特定编排平台
- 需确保代理高可用，建议至少双节点部署+健康检查
