你的思路方向完全正确——把分散的硬编码配置集中到独立的config模块/文件里，是解决这类老项目配置管理混乱的核心步骤。下面我会详细讲落地步骤，以及比分支管理配置文件更优的替代方案：

一、落地你的config模块+JSON配置方案 #

1. 第一步：集中抽离配置项 #

• 先全局扫描所有代码（PHP、JS文件），把硬编码的数据库名称、API URL、资源路径等配置项全部整理出来，形成一个统一的配置结构，比如：

  // config/env.json
  {
    "database": {
      "name": "prod_db",
      "host": "prod-db.example.com"
    },
    "api": {
      "base_url": "https://prod-api.example.com"
    },
    "resources": {
      "static_path": "/prod-static/"
    }
  }
  

• 逐个替换代码中的硬编码：
  • PHP中读取配置：

    $config = json_decode(file_get_contents(__DIR__ . '/../config/env.json'), true);
    $dbName = $config['database']['name'];
    

  • JS（jQuery/Angular）中读取：可以通过异步请求加载，或者如果是构建后的项目，直接把配置注入到全局变量里

2. 第二步：Git分支的配置冲突规避 #

因为你计划用不同分支对应不同环境，要保证各分支的env.json不被合并覆盖，有两种可靠方式：

• 方式一：设置Git合并策略
  每次合并分支时，用ours策略保留当前分支的配置文件：

  git merge -X ours <目标分支>
  

• 方式二：全局配置自动忽略合并冲突
  在项目根目录创建.gitattributes文件，添加：

  config/env.json merge=ours
  

  这样Git会自动在合并时保留当前分支的env.json版本，无需每次手动指定策略

3. 第三步：多模块的配置共享 #

如果你的各个模块还是独立仓库，可以把config仓库设为每个模块的Git子模块：

git submodule add <config仓库地址> config

这样每个模块都能引用到统一的配置仓库，同时各环境分支的配置文件保持独立；如果已经合并成单一仓库，直接把config目录放在根目录，所有模块从根目录读取即可

二、更优方案：配置模板+环境变量（避免分支依赖） #

其实用分支管理配置文件还是有隐患——比如后续分支合并时容易误操作，或者新环境需要重复分支。更灵活的方式是用模板+环境变量，完全让配置和分支解耦：

1. 创建配置模板 #

编写config/env.template.json，用占位符代替具体值：

{
  "database": {
    "name": "{{DB_NAME}}",
    "host": "{{DB_HOST}}"
  },
  "api": {
    "base_url": "{{API_BASE_URL}}"
  }
}

把这个模板文件提交到Git仓库，同时把实际的env.json加入.gitignore，不提交到仓库

2. 环境变量注入 #

• 在每个环境的服务器上设置对应的环境变量（比如通过Apache/Nginx的SetEnv，或者服务器的系统环境变量）
• 编写一个部署脚本（PHP或Shell），在部署时读取环境变量，替换模板中的占位符，生成实际的env.json：
  比如Shell脚本示例：

  envsubst < config/env.template.json > config/env.json
  

• 前端代码的话，可以用构建工具（比如Webpack）在构建时把环境变量注入到配置中，避免前端直接访问敏感信息

3. 敏感信息处理 #

对于数据库密码这类敏感内容，绝对不要存到Git或配置文件里，直接用环境变量读取，比如PHP中：

$dbPassword = getenv('DB_PASSWORD');

三、迁移注意事项 #

• 先小范围测试：先抽离一两个配置项替换，验证功能正常后再全量迁移，避免影响现有业务
• 配置缓存：如果是高频读取的配置，可以考虑缓存（比如PHP中存到内存缓存），提升性能
• 测试环境验证：在dev/abcdev环境先完成配置迁移，确认所有功能正常后再推到production

内容的提问来源于stack exchange，提问作者Ram