多环境配置治理：开发、测试、生产连接信息如何隔离

应用接入数据库后，最怕的不是配置多，而是配置混。开发环境连到了测试库，测试任务误写了生产库，生产密码提交到代码仓库，本地调试用了高权限账号------这些问题一旦发生，影响往往比普通 Bug 严重得多。

本文围绕金仓数据库应用接入场景，讲清楚 Windows 11 本地开发、测试环境、生产环境之间的连接配置如何隔离，避免"环境串线"和"密码裸奔"。

@ $toc$

一、多环境混乱的典型问题

其实咱们平时遇到的事故，往往往往仅仅只是这么几种情况：

开发人员在自己电脑的 application.yml 里头，直接写了生产库的地址。这是一个问题。
测试环境拿去用了生产的账号，这个也是经常发生的。
生产的密码跑到 Git 仓库的历史记录里去了。
好几个环境都共用同一个数据库账号。那出了事你想查来源，根本查不出来。
本地弄的一些临时配置，稀里糊涂就打进生产包里了。
连接池的参数在哪个环境都一模一样。那生产环境的连接预算就很容易失控了。

那么这些问题出现了。你光靠嘴上提醒大家，是没用的。那要怎么解决呢？原因在于你得从配置结构和权限边界上去管。

二、推荐的配置文件结构

通常来说，一个 Spring Boot 项目，我建议你最起码得拆成这几个文件：

text 复制代码

application.yml
application-dev.yml
application-test.yml
application-prod.yml

那个 application.yml 里头呢，其实就放点公共的配置就行了：

yaml 复制代码

spring:
  application:
    name: kb-app-demo

server:
  port: 8080

接着咱们看开发环境：

yaml 复制代码

# application-dev.yml
spring:
  datasource:
    url: jdbc:kingbase8://192.168.10.101:54321/kb_app_dev
    username: app_user_dev
    password: App_user_dev_123
    hikari:
      pool-name: kb-dev-pool
      maximum-pool-size: 5
      minimum-idle: 1

那测试环境的话：

yaml 复制代码

# application-test.yml
spring:
  datasource:
    url: jdbc:kingbase8://192.168.10.102:54321/kb_app_test
    username: app_user_test
    password: App_user_test_123
    hikari:
      pool-name: kb-test-pool
      maximum-pool-size: 20
      minimum-idle: 5

到了生产环境：

yaml 复制代码

# application-prod.yml
spring:
  datasource:
    url: ${KB_DB_URL}
    username: ${KB_DB_USER}
    password: ${KB_DB_PASSWORD}
    hikari:
      pool-name: kb-prod-pool
      maximum-pool-size: ${KB_DB_POOL_MAX:30}
      minimum-idle: ${KB_DB_POOL_MIN_IDLE:5}

这里我得重点提一句。生产环境里，你千万、千万不要把真实的密码写死在配置文件里头。

三、用 profile 明确启动环境

本地开发：

powershell 复制代码

java -jar kb-app-demo.jar --spring.profiles.active=dev

测试环境：

bash 复制代码

java -jar kb-app-demo.jar --spring.profiles.active=test

生产环境：

bash 复制代码

export KB_DB_URL='jdbc:kingbase8://10.10.20.15:54321/kb_app'
export KB_DB_USER='app_user_prod'
export KB_DB_PASSWORD='生产密码'
export KB_DB_POOL_MAX='30'
export KB_DB_POOL_MIN_IDLE='5'

java -jar kb-app-demo.jar --spring.profiles.active=prod

建议启动日志打印当前 profile：

java 复制代码

import org.springframework.core.env.Environment;
import org.springframework.stereotype.Component;
import org.springframework.boot.ApplicationArguments;
import org.springframework.boot.ApplicationRunner;

@Component
public class ProfileLogger implements ApplicationRunner {
    private final Environment environment;

    public ProfileLogger(Environment environment) {
        this.environment = environment;
    }

    @Override
    public void run(ApplicationArguments args) {
        System.out.println("active profiles: " + String.join(",", environment.getActiveProfiles()));
    }
}

如果生产环境启动时没有明确 profile，应当直接失败，而不是使用默认配置悄悄启动。

四、不同环境使用不同账号

不要让开发、测试、生产共用同一个数据库账号。建议至少区分：

环境	示例账号	用途
开发	`app_user_dev`	本地开发联调
测试	`app_user_test`	测试环境验证
生产	`app_user_prod`	生产业务访问
报表	`report_user_prod`	生产只读查询

这样做有几个好处：

数据库侧可以根据账号判断访问来源。
某个环境账号泄漏，不会直接影响其他环境。
权限可以按环境收敛。
审计日志更容易分析。

五、不同环境使用不同数据库或 Schema

如果资源允许，开发、测试、生产应该使用不同数据库实例或不同数据库。至少也要使用不同 Schema，避免对象混用。

例如：

text 复制代码

开发库：kb_app_dev
测试库：kb_app_test
生产库：kb_app

不要在同一个生产库里用 test_ 前缀表做开发测试。临时表、测试数据、误操作都可能影响生产。

六、禁止把生产密码提交到仓库

建议在 .gitignore 中排除本地私有配置：

gitignore 复制代码

application-local.yml
.env
*.secret

如果历史上已经提交过生产密码，不能只删除当前文件------Git 历史里仍然存在。应该立即更换密码，并按企业安全流程清理仓库历史中的敏感信息。

生产密码应该来自：

环境变量。
配置中心。
密钥管理系统。
容器编排平台的 Secret。

不要通过微信群、文档截图、代码注释等途径传播生产密码。

七、启动时校验目标环境

为了防止应用连错库，可以在启动时校验当前数据库名和用户。

java 复制代码

import java.util.Map;
import org.springframework.boot.ApplicationArguments;
import org.springframework.boot.ApplicationRunner;
import org.springframework.core.env.Environment;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.stereotype.Component;

@Component
public class DatabaseEnvChecker implements ApplicationRunner {

    private final JdbcTemplate jdbcTemplate;
    private final Environment environment;

    public DatabaseEnvChecker(JdbcTemplate jdbcTemplate, Environment environment) {
        this.jdbcTemplate = jdbcTemplate;
        this.environment = environment;
    }

    @Override
    public void run(ApplicationArguments args) {
        String profile = String.join(",", environment.getActiveProfiles());
        Map<String, Object> row = jdbcTemplate.queryForMap(
                "select current_database() as db_name, current_user as user_name"
        );

        System.out.println("profile=" + profile + ", db=" + row.get("db_name") + ", user=" + row.get("user_name"));
    }
}

生产环境可以进一步做强校验：如果 prod profile 下连接的不是生产库名或生产账号，应用直接启动失败。

八、连接池参数也要分环境

开发环境可以小：

yaml 复制代码

maximum-pool-size: 5
minimum-idle: 1

测试环境可以接近压测：

yaml 复制代码

maximum-pool-size: 20
minimum-idle: 5

生产环境根据压测和连接预算配置：

yaml 复制代码

maximum-pool-size: ${KB_DB_POOL_MAX:30}
minimum-idle: ${KB_DB_POOL_MIN_IDLE:5}

不要让开发配置带到生产，也不要让生产连接池参数在开发环境里制造不必要连接。

九、多环境发布检查清单

检查项	要求
profile	启动命令明确指定
数据库地址	与目标环境一致
数据库名	开发、测试、生产隔离
数据库账号	不同环境不同账号
密码来源	生产不写入代码仓库
连接池参数	按环境配置
启动自检	打印脱敏环境信息
权限边界	生产账号最小权限
日志	不打印密码

十、小结

多环境配置治理的目标是让"连错库"变得困难，让"密码泄漏"更容易被发现，让"连接来源"可以追踪。配置文件分层、profile 管理、账号隔离、环境变量注入和启动自检，是应用接入金仓数据库必须建立的基本工程规范。

下一篇我们继续看账号和权限，把应用账号、报表账号、运维账号分层设计清楚。