把数据库连接、第三方接口地址、内部服务调用地址直接写死在代码里，这种做法在小项目阶段看似省事，一旦项目进入测试、预发、生产多环境流转，或者服务实例需要弹性扩缩容，问题就会集中爆发。测试环境明明跑得好好的，打包发布到生产却连的还是测试库；某个下游服务换了IP，全项目几十个文件挨个改一遍。解决这个问题的核心思路只有一个：让配置与代码分离，而环境变量和配置中心正是实现这一目标的两种主流手段。
服务地址硬编码到底有哪些坑
先看一段典型的硬编码代码，很多老项目里都能找到类似的影子：
public class OrderService {
// 订单服务直接写死了用户服务的地址
private static final String USER_SERVICE_URL = "http://192.168.1.100:8081";
public UserDTO getUser(Long userId) {
return restTemplate.getForObject(
USER_SERVICE_URL + "/api/users/" + userId, UserDTO.class);
}
}这段代码的问题不止一个。首先是环境不可切换，测试环境和生产环境的用户服务地址显然不同，硬编码意味着每次发布都要改代码重新编译，极易出现把测试地址带到线上的事故。其次是部署弹性丧失，如果用户服务部署了三个实例做负载均衡，调用方根本无从感知，单点地址一旦宕机，整个订单链路全部失败。
更深层次的隐患在安全层面。数据库连接串、带密码的中间件地址、第三方付费API的密钥地址，这些敏感信息一旦写进代码仓库，就会随着Git历史永久留存。就算后续提交时删掉了，历史提交记录里依然可以翻出来，团队成员离职后风险更难评估。此外，代码审查时配置变更和业务逻辑变更混在一个提交里，排查问题时也很难快速定位是哪个配置改动引发了故障。
环境变量方案：最轻量的配置分离手段
环境变量是操作系统层面提供的键值对机制，几乎所有语言和框架都原生支持读取。它的核心优势是不引入任何额外组件，运维人员只需在部署时注入不同的变量值，同一份制品包就能跑在不同环境里，真正做到一次构建、处处运行。
以Spring Boot为例，配置文件中通过占位符引用环境变量，并给出默认值兜底：
# application.yml
user:
service:
# 读取环境变量 USER_SERVICE_URL，未设置时使用localhost兜底
url: ${USER_SERVICE_URL:http://localhost:8081}
db:
url: ${DB_URL:jdbc:mysql://localhost:3306/order_db}部署时注入变量即可切换地址，在Linux下可以这样启动：
export USER_SERVICE_URL=http://user-service-prod.internal:8081 export DB_URL=jdbc:mysql://prod-db.internal:3306/order_db java -jar order-service.jar
如果使用Docker，通过-e参数或者--env-file注入更干净：
docker run -d \ -e USER_SERVICE_URL=http://user-service:8081 \ -e DB_URL=jdbc:mysql://mysql:3306/order_db \ order-service:1.0.0
Kubernetes场景下则推荐用ConfigMap统一管理环境变量，再通过envFrom批量挂载到Pod中，这样配置变更只需改ConfigMap再滚动重启，不需要重新打镜像。环境变量的局限也很明显：它是进程启动时确定的，运行期无法动态修改，而且缺乏统一的管理界面和变更审计，变量多了之后散落在各个部署脚本里，维护成本会逐渐上升。
配置中心方案：集中管理与动态刷新
当服务数量超过十个、配置项成百上千时，环境变量就有些力不从心了，这时配置中心的价值就体现出来。以国内使用最广泛的Nacos为例，它同时提供配置管理和服务发现能力，配置存储在服务端，应用启动时拉取，运行期还能监听变更实时刷新，不用重启进程。
先在Nacos控制台创建一个Data ID为order-service-dev.yaml的配置，内容就是原来的application.yml。然后在项目中接入客户端：
# bootstrap.yml
spring:
application:
name: order-service
cloud:
nacos:
config:
server-addr: ${NACOS_ADDR:127.0.0.1:8848}
file-extension: yaml
discovery:
server-addr: ${NACOS_ADDR:127.0.0.1:8848}配合@RefreshScope注解，配置变更后Bean中的属性值会自动更新：
@RestController
@RefreshScope
public class OrderController {
@Value("${user.service.url}")
private String userServiceUrl;
@GetMapping("/users/{id}")
public UserDTO getUser(@PathVariable Long id) {
return restTemplate.getForObject(
userServiceUrl + "/api/users/" + id, UserDTO.class);
}
}配置中心的命名空间机制天然解决了多环境隔离问题，dev、test、prod各用一个命名空间，互不干扰；Group则可以按业务线划分。更实用的是历史版本回滚功能，某次配置改错导致线上故障时，在控制台一键回滚到上一版本，比翻Git记录快得多。变更审计日志能清楚记录谁在什么时间改了什么，对合规要求高的团队尤其重要。更进一步，如果直接使用Nacos的服务发现能力，调用方根本不需要知道服务地址，通过服务名从注册中心获取实例列表再配合负载均衡，这才是微服务体系下彻底消除服务地址硬编码的终极方案。
两种方案如何选择
环境变量和配置中心并不是二选一的关系，实践中往往组合使用。环境变量适合承载那些启动时就固定、几乎不变的配置，比如配置中心自身的地址、日志级别开关这类引导性参数——配置中心的地址本身就不可能存在配置中心里，必须靠环境变量或启动参数注入。而业务配置、需要动态调整的开关、多环境差异大的地址信息，则交给配置中心统一管理。
一个简单的判断标准：单体应用或小团队项目，环境变量加一个部署脚本的.env文件完全够用，引入配置中心反而是负担；微服务架构、多团队协作、需要灰度发布和动态推送的场景，配置中心是必选项。无论选哪种，底线是一样的：代码仓库里不应再出现任何具体的服务地址和敏感连接串，配置与代码彻底分离后，环境切换、弹性部署和安全管理才能真正落地。